In the summer of 2009 I revisited my 2004 summer apprenticeship at Object Mentor. What follows is the original 2004 post and then some 2009 commentary.

Other than a little bit of time spent with Micah explaining Word Press to Bob, I was able to code all day. Whoo! Some hints from Micah yesterday and a lot of trial and error today led me to finally get the hang of testing methods that rely on user input from the keyboard. When the program is really running, I pass in a regular old keyboard InputStream (System.in) to my userInput method. However, in a test, I can load up a ByteArrayInputStream with all the values I want entered (separated by newlines, of course) and then every time a function I’m testing calls for a user input it gets my preset values instead. Which is pretty darn cool.

Of course this took a large chunk of the day to get it working exactly how I want. Java IO can be a wee bit tricky. The rest of my time was spent applying the finishing touches to my long-neglected TDD Tic Tac Toe game. Should be ready for prime-time tomorrow.

Speaking of tomorrow, I’ll be taking a class with James Grenning: Test Driven Design and Refactoring. Unit testing has been interesting, but I’m itching to see how FitNesse extends things. Since the paying customers want the class in C#, there’s a good chance that I’ll revisiting Microsoft Visual Studio. We gotta get Jet Brains’ add-on installed soon because life is unpleasant without refactoring tools

When I applied to ThoughtWorks I used the trick I learned above in my coding submission to test input from the command line. Later on when I got hired I asked to see what people said about my code and one of the comments was “Some of the things he tested would never fail.” First of all – the anonymous reviewer was right. One can reasonably assume that core Java IO will work and so it doesn’t have to be tested in your application. But second – it was pretty cool to see that I had tested way more than a ThoughtWorker thought was necessary.