4 ms·
Also, code that controls hardware is very hard to test. Consider writing tests for the the Linux kernel's device drivers. It would be very difficult because mo
by __david__ 14y ago
Also, code that controls hardware is very hard to test.
Consider writing tests for the the Linux kernel's device drivers. It would be very difficult because most of the problems have to do with hardware being buggy/underspecified, not with the software being wrong in a testable way.
In order to test a UART driver you have to to simulate the way the UART worked, which means that you wouldn't catch bugs if your understanding of the hardware was wrong. Most of the time spent would be recreating the internal logic of the UART and it wouldn't actually benefit you unless you got it right.
The other option to test the UART is to have a rig set up that where you can run the code on the device and have the serial port looped back or go into another computer that checks the result. But that (by definition) means special hardware is required to run that test, which makes it way less useful as an automated test.
Neither of those situations is amenable to TDD.
- mpweiher 14y agoThere's actually a fairly simple way to deal with external systems that to me would seem to apply to hardware as well: First, write code that "tests" the actual hardware, that means it drives the hardware and checks its results. Verify using whatever means you have available that it drives the hardware correctly. Second, create a variant of this first test (class) that runs against your simulator (checking for the same results). I used a trivial subclass that changed nothing except replacing the device interface with the simulator. Third, write your simulator against these tests. Fourth, use your simulator to test the remainder of your system without requiring the hardware/external system. Extend when you make use of new features, and occasionally test against the real system/hardware...