How do you unit test code that does nothing?

I been working on a CPU emulator in ActionScript recently more as an exercise in how to write good code, try some methodologies and tools than I've not been using in other projects and improve my understanding of the CPU's instruction set. Someone will hopefully find it useful when I open source it.

We all know that code should be tested and that best practice involves writing unit tests and/or test driven development. Both Flash Builder and Flex Builder make it easy to write and run unit tests with FlexUnit so there's really no excuse not to. Despite that is the Flex SDK itself not having unit tests unit tests and the countless projects I've been involved in for one reason or the other that don't have unit tests (usually the excuse is we don't have time or budget to write tests - doh!), but that's another story.

I'm writing the tests for the instruction set and most of it is fairly straight forward, test adding two numbers together, test if a register is zero etc and then I come across this instruction "NOP". For those who don't know machine code mnemonics NOP is an instruction that does nothing, it's used as padding or to eat a few CPU cycles. How do you test something that does nothing? It's not easy to test. You could take a snapshot of the memory before and after running the instruction and compare byte by byte and check that nothing has changed. I know that from looking at the function that it does nothing so in this case I can be fairly confident that it does what is says. However it did make me think about what unit tests can and should test.

Generally unit tests will only test for correct behaviour, a few boundary conditions or null parameters and the like but they don't often test for side effects or the completely unexpected. In most cases your code should be written to prevent any side effects but every now and then you going to run into some code that you just can't test 100% without a large amount of effort. The solution is to be pragmatic (unless you're writing software for controlling rockets or life support machines) just go on to write the next test, you'll waste far too much time trying to test something that may not happen and your time can be better spent writing other tests that add value.

Also remember because some code has been unit tested doesn't mean it will work 100% of the time. Units tests give you increased confidence that you code will do what you expect it to do but that's all. They will not test everything but having unit tests is far better than having none at all.