See Braidy Tester Read Code. Read, Braidy Tester, Read!

I've been reading through code for one of the tools we are investigating using.  This particular tool has been used by lots of other people for years, so any bugs that would prevent us from using it have likely been found by now.  I'm not reading this code for the express purpose of finding bugs, anyhow.  A lot of our testing will use this tool, so we want to know that taking this dependency will make our testing better, not worse.

A lot has been written lately about reading code.  Diomidis Spinellis wrote "Reading, Writing, and Code" plus an entire book on the subject, Eric Lippert wrote "Reading Code Is Hard" in two parts (Part 1 and Part 2, "the" Wiki has Tips For Reading Code, and the always funny Matt Warren gave us a glimpse of "Programming In [His] Brain", just to name a few.  I don't know if this is just an interesting coincidence along the same lines as every movie studio putting out similarly-themed movies every year ("Coming soon to a theater near you:  Alistair Cooke reads leaked Windows 2000 source code!"), but reading code seems to be front and center these days.

Reading a foreign language is often easier than writing it, but the opposite is true for code.  Writing code involves converting the model of the system or algorithm in your head into a bunch of text the compiler understands.  Reading code, on the other hand, involves rebuilding that model of the system with that compiler-ready text as your only guide.  This is hard enough to start with, but if the author attempted "clever" tricks, named members badly, let comments rot (or left them out entirely), or committed any of the other crimes I continually rail against, understanding the code can be nearly impossible.

But what doesn't kill you makes you stronger, as the saying goes.  Developing the ability to read and understand unfamiliar code (including, as everyone always loves to say, your own code six months from now) is vital to your success in becoming an expert developer or tester.  More important even, I dare say, than developing your coding skills.

As for reading unfamiliar test cases, well, everything I just said goes double.  Good test cases are even harder to write than good code, and (yes) much harder to find, so the ability to read and understand them is highly prized.  The upside, though, is that the paucity of good test cases and good code provides plenty of opportunity to practice!


*** Comments, questions, feedback?   Want a fun job on a great team?  Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com.  I need a tester and my team needs a data binding developer, program managers, and a product manager.  Great coding skills required for all positions.

Comments (2)

  1. Mark Mullin says:

    The discussion about reading and writing code has been around for a while, off and on – another source you might want to consider is Adele Goldberg’s (Smalltalks mom) paper on ‘The programmer as reader’ or something to that effect – she started with the premise that english courses for would be writers focused on reading far in advance of any actual writing, and she thought that was the way things should be in programming should be too.

    Of course, you have to remember the corollary

    If it was hard to write, it _should_ be hard to understand 🙂

    As far as testing goes in general, another fun approach is to use genetic algorithms for simple functions that may have boundary conditions but don’t depend on side effects or sequenced calls – I used this approach to test the core numerical and 3D math libraries for Taligent, a long time ago – fitness function was simple, catch and count exceptions

  2. SpiderMan says:

    Ya, I think it’s good for both developers and testers to read code if you have time to. It’s a very time cosuming work! But just as you said, it can make you stronger.

Skip to main content