Unit Testing Guidelines


NUnit has been selected as the preferred unit testing framework for the emulation suite.  While Visual Studio 2008 has a version with built-in unit testing, it is part of a commercial version that is not widely available to the public.  NUnit is free and open source; however, you are free to make suggestions if you believe a different unit testing framework will be of greater benefit.

Short-Term Memory Avoidance

Ideally, someone else should write the unit tests for your emulation code.  That person should strictly reference any technical documentation instead of your code.  If you must write your own unit tests, please wait a while before running the tests (or write the tests first).  Refer to the technical documentation only, not your source code.  This is important because your initial emulation code will be based on your interpretation of often-confusing technical documentation.  You do not want to write a unit test based on the same interpretation.


It is good to write a unit test that executes a snippet of machine code from a book or online web site.  Your unit testing code should verify only the documented behaviors from the book.  Do not make assumptions or try to write a better unit test by testing for behaviors that "you know should happen".  Stick to whatever the author of the snippet stated would happen.  And course provide a full reference (e.g. page number, web site address, book name, etc).

Processor Instructions

The CPU is the core of an emulator and must therefore be heavily covered with unit tests.  A rich set of tests is important because the emulation engine will constantly undergo performance enhancements.  A set of tests is helps avoid performance changes that subtly break code.  Create at least one test per unique CPU instruction.  Note that assembly instructions (e.g. such as MOV) are often aliases for multiple CPU opcodes.  Be sure to test each opcode separately.