Test on Your Host Computer as Much as Possible

The target computer is a fun toy, and once it starts working, it seems to be the natural place to do all of your testing. After all, that’s where the software has to run eventually—why not test it there?

That reasoning is invalid. You should test as much of your software as possible on your host computer system. If your host is running a different processor, modify your Makefiles so that the software can be built for your host or target. If your software depends on hardware that can only be found in the target, you can still test a lot of your code on the host by #ifdef -ing out the parts of the code that actually need the target’s hardware.

Testing your software on your host is important for these reasons:

• Access to debugging tools

  You probably have better debugging tools—and more control over them—on your host computer than on your target computer. The host computer is probably a desktop computer running Linux. On it you probably have a large array of great software development tools—not just the compiler tool chain, but debuggers, debug libraries, memory bounds–checking libraries, tools such as strace, and so on. Chances are that many of these tools won’t fit on your target box; they may not even have been ported to the processor you’re using. But that doesn’t mean that you can’t use them. Compiling your software on your host machine allows you to use this array of tools for debugging your code—once you’re satisfied with your changes, you can recompile the code for the target.

• Simpler debugging cycle

  The debugging cycle almost certainly will require considerably less effort on your host than on your target. The less time it takes you to start testing code that you have just changed, the better—especially if you’re like me, and prefer to change a small bit of code and then run it, then change more small bits and run them. Your host computer probably compiles code for itself just as fast as it compiles code for your target; but once it’s compiled, you don’t need to move it anywhere—you can just run it where it is. It may take you several minutes (or longer) to move the code to the target, just to find out that you’ve made a mistake and have to repeat the whole process.

Of course, you do need to do some testing on your target, and the target’s environment may be very different from the host’s, not only in terms of hardware, but also the runtime environment—C libraries, other libraries, utility programs, and so on. If you go too long without moving the development code to the target computer, you may waste a lot of time backtracking because you made some incorrect assumptions about the target environment. This is especially true in the very beginning of a project, when you’re new to the environment—the first order of business should be to get the hardware up and running, and then test your software on it at least once a day.

Sometimes it just doesn’t make sense for you to debug your software on your host machine. For instance, if you’re implementing a driver for hardware that can only exist on your target, you obviously can’t do much beyond developing the stub code on your host machine. You may also want to steer clear of testing any “dangerous” software on your host machine. For instance, any software that, as part of its functionality, creates a new filesystem on the first partition of the first hard drive it sees should not be tested on your host machine—even if you believe that the dangerous code path cannot be reached. You may be correct when you originally think it, but as you test and debug your software, you may accidentally activate the wrong code path and blow away your machine.