There are many circumstances where you are working on a program but have access to a working (or nearly working) executable.

• In the real world, very few programming assignments are to write something new from scratch. Much more often, you will be adding new features to an existing program, or fixing bugs in an existing program, or trying to improve the performance of an existing program.
• Even if you are developing a whole new program, there may be an older one already in use that is being replaced because it is in a older programming language that no one in the company cares to maintain, or runs only on older hardware or operating systems that are due for replacement, etc.
• And in the academic world, you will often find that instructors¹ provide executable solutions to assignments so that you can see what the finished product of an assignment is supposed to look like.

Whenever you find yourself working on a system for which you already have a (nearly) working executable, you can take advantage of this by doing head to head testing, in which you

1. Run the old code on a set of inputs, capturing the outputs into a file.
2. Run your new code on the same set of inputs, capturing the outputs into a different file.
3. Compare the two output files to see what, if any, differences you can find between them.
   • Those differences might represent bugs in your new code.
   • Or they might be due to bugs in the old code that you have just successfully fixed.
   • Or they might represent the new behavior or functionality and that you were working to add ot the old program.

Whatever the reason, it’s the differences in outputs that are particularly interesting. Spotting those differences can be quite tricky, however, if they are buried in a sea of nearly identical outputs or if the differences are “invisible” changes like adding blanks at the ends of lines or improperly indenting output.

Luckily, there are simple tools that you can use to find and highlight those differences.

[]