What I Learned by Contributing to FitNesse

by Marisa Seal

As of today, I am officially a contributor to FitNesse. I contributed a new feature idea and its implementation (the initial idea was borrowed from FitLibrary’s SequenceFixture but morphed a bit based on suggestions from Bob Martin), and also worked on Slim version detection. I am not a developer by training nor trade, but armed with basic coding skills and fueled by the guidance and what I can only describe as the graciousness of Uncle Bob, I was successful. The experience was trying, exciting, and actually pretty fun. While I learned an awful lot more than I’m going to detail here, I think I had three really important realizations while working on the updates.

TDD Works!

Given that I am a tester, I have read/learned about, discussed, and even advocated TDD. Given that I do not (usually) write production code, I had never actually tried it. I decided I’d give it a go since I needed to write unit tests for my updates anyway.

The existing unit tests for the class I updated served as my guide. I wrote a test to verify the simplest case of the new feature. I ran it – here’s the interesting thing: it passed. This surprised me, but also informed me that I did not need to make any changes to the code for the simplest case. The update involved implementing a special character to invoke a different processing scheme for function calls in Slim Script tables, so I had figured that I’d at least need to update the code to ignore the special character in the simplest case…but as the unit test proved, I did not.

I wrote a second unit test to verify another simple (yet different) case – this one failed as expected. I added code to the class in question, ran the test, and saw it fail again. But aha – I also saw why it failed, and that information helped me find my mistake. At this point I’d like to say that I made the fix, ran the test, and saw it pass – but it didn’t happen that way. I went through a few iterations of running the test and fixing my code.

The test finally passed, and I ran the entire suite of tests for the class. They all passed. The most appropriate word I can find to describe that moment is epiphanic. It was then that I truly understood and appreciated two of the benefits of TDD I have often heard:

1. Practicing TDD can help ensure that only necessary code is implemented, since the goal of writing/updating the code is to make one test pass. Remember, I didn’t even need to write any code to make the first test pass.
2. Having a suite of unit tests – a byproduct of practicing TDD – can provide confidence that updates have not unintentionally changed existing behavior. The bonus is that unit tests are fast, so the feedback can be almost instantaneous. For example, the entire suite of 208 unit tests for the class I updated runs in under 1.5 seconds on my machine.

Having an understanding of a practice is one thing; having experience implementing the practice is another. Upon reflection, I now find it odd that I could have advocated TDD without having tried it myself.

Refactoring is more than just “Changing”

I’m a bit embarrassed to admit this, but up until recently, I used the word “refactoring” as a substitute for “changing,” since I thought that’s what refactoring meant. I thought it was just a dev-ified word for “changing” or “improving.”

Once I submitted the first update to Bob Martin, I asked him for feedback. I was quite proud that the new feature took only about a dozen new and updated lines of code, but I wondered what I could have done better. Uncle Bob told me that since I had added a couple lines of code to an existing function, the function’s length was getting to the point where he’d want to extract some of the functionality – he suggested extracting a particular loop to a “method object.” I immediately Googled “extract to method object” and found information about it on refactoring.com. I quickly realized that refactoring actually encompasses specific techniques that address specific scenarios – refactoring is not just changing code.

I’m not as embarrassed to admit that I really had no clue how to execute “extract to method object.” I ruminated about it for a few days, and finally just told Uncle Bob that I didn’t know how to get started. He sent me the code, explained step-by-step how he got to the end result, but still allowed me to commit the change myself…which leads me to my last point.

I think I know one reason why he’s called “Uncle” Bob

There were many times throughout the last few weeks that I wondered when Uncle Bob would say to me “I’ll just do it myself – it’ll be faster that way.” That certainly would have been a true statement. Being that I am not – as I stated before – a developer by training or trade, I was surprised that he even supported the idea of me actually committing code changes when I first contacted him to suggest the new feature. It turns out that my fear and surprise were completely unfounded. Uncle Bob continually offered guidance and encouragement, and always ended his messages with “Let me know if you need any help.” Here’s the kicker: he meant it, too.

I really did feel like I was the lucky recipient of mentoring by a person who has literally “written the book” (multiple books, actually) about software craftsmanship.

I hope that some FitNesse users find the new feature valuable, and that I will be able to contribute to FitNesse again in the future. It was a great experience.