YAJII I chose you!
Thursday, August 20th, 2009So, I’ve basically finished my refactor/resuscitation of PyGP (except for the part where I actually package it and release it). So it’s time to select my next victim.
Since I mostly do Java at work, I thought I’d select a Java project. I’ve found such a project in YAJII, a java implementation for an IRC client. It doesn’t appear to have any unit tests (or a build system) but it does have some documentation. The author’s current webpage is here.
My real goal would be to use this as a project for a coding Kata, potentially to be presented at the OSUG, depending on the interest I get, I could then spin off a sub-group or another meetup for code Katas in general.
Before I’m able to do a Kata I’ll have to do the following:
- Get it to build with ant or some other build tool (ant + ivy, maven, buildr, scons…)
- Run the “testbed” application through it’s paces.
- This would follow the context driven testing methodology, maybe a 1/2 hour session to find a big problem to fix. “Go through all the menus to get a feel, read the user manual create a test outline.”
- After the problem the big problems from the testing perspective have been found, I’ll use the saff squeeze to isolate it with a unit test. This will be an iterative process of getting the program into a test framework, starting with a “smoke test” covering much of the stack and iterating towards the point that the saff squeeze will lead me to. These will use various techniques from Working Effectively With Legacy Code to get the code unter test.
- Finally, use techniques from WEWLC to fix the problem/add the feature found in exploratory testing.
Since this is a Kata, it will mostly focus on getting good technique. It’s okay to go down false allies to figure out what’s happening. The techniques that will be covered are:
- Dealing with build systems, especially of code that isn’t under one yet.
- Exploratory testing (Context-driven school). A very different skill that most developers don’t have.
- Getting code under automated tests.
- Converting a exploratory test into a fully automated test. Both acceptance level and unit level.
- This includes dependency breaking, the saff squeeze and test doubles.
- Fixing code based on automated tests.
- Verifying a code fix manually after automated tests.
I think this would hit a lot of the skills needed for software maintenance. This seems to be large enough to break into multiple Katas.
My concern is that it may be too big to do as an introductory Kata, maybe something else would be better? Bowling scores, or maybe one of the problems from S.Lott’s blog?



