Exercise 26: hexdump

You've done a warmup with xargs and are now working in the cycle of code then audit. You are now going to try to complete the next challenge with a "Test First" approach. This is where you write a test that describes your expected behavior, and then you implement the behavior until the test passes. You are going to be copying the hexdump utility and attempting to match your version's output to the real version's. This is where Test First development really helps since it automates the process of mimicing another piece of software.

This technique is very useful when you need to write a replacement for a terrible piece of software. A common job in software is to work on a project that aims to replace an older system with a more modern implementation. An example is replacing an old COBOL banking system with a fresh, new, hot Django system. The motivation is typically to make it easier to maintain and extend by using something easier to work with than the old system. If you can write a set of automated tests that validate the behavior of the old system and then point that test suite at the new system, then you have a way to confirm that your replacement works...mostly. Trust me, these replacement jobs are nearly impossible and don't succeed too often, but an automated test helps.

In this exercise you'll add to your process the following:

• Write a test case that runs the original hexdump in a scenario you need to implement. Let's say the -C option. You'll either need to use subprocess to launch it or simply run it ahead of time and save the results to a file that you load.

• Write the code that makes this test work by having the test run your version of hexdump and then compare the results. If they aren't equal, then you didn't do it right.

• Then audit both the test code and your code.

I chose hexdump because the difficulty is in replicating its strange output format for viewing binary data. There's nothing too complicated about how it works. It's just matching the output that you need to get right. This helps you practice test first testing.

NOTE: When I say "write a test first" I do not mean a whole massive test.py file with all the functions and huge amounts of imaginary code. I mean what I've taught in the past. Write a little test case--maybe just 1/10th of one test function--then write the code to make that work, and then bounce back and forth between the two. The more you know about the code the more of the test case you can write, but don't write reams of test code with nothing to run against it. Work incrementally instead.