FitNesse with Bob Martin – Part 2

Stephen Wright — Mon, 04 May 2009 00:48:46 GMT

FitNesse with Bob Martin – Part 1

Stephen Wright — Sat, 11 Apr 2009 05:55:00 GMT

On Wednesday, Uncle Bob Martin came out to the Chicago ALT.NET meeting to demo FitNesse. Here is Part 1 of the meeting

My Unit Testing Challenge

Stephen Wright — Tue, 23 Oct 2007 21:02:00 GMT

I've always thought of myself as a decent programmer. I'm able to find solutions for people and I get rave reviews on how great something works. However, there's always been a part of me that knows that I can program it better using agile methods and sound fundamentals.

I haven't taken the time to implement unit testing in my application because of time constraints. It's been one of those things that has always left a sour taste in my programming mouth. For an application that spans 300 pages, 200 controls and 100 Controller Modules, you'd think that I'd have a better handle on the code and a testing plan in place.

Instead of automated testing, we have our QA team go through printed scripts (some over 200 pages). Some of the site is still undocumented and we do not have a formal testing plan, so we have to remember to test it out before it's sent to the customer. As a rule of thumb, we've always set aside double the time we estimate for programming. Not the most efficient way to estimate, but it's worked for us in the past. We've gotten to the point in a program that it is no longer practical.

Why am I able to get away with this? I am the architect. I am involved from the kickoff to the deployment. I am creative control. I can tell you in 30 seconds whether or not a certain feature exists. If something doesn't work properly, I'm the one to fix it.

The solution to this is putting in unit tests for all of the code in the site.

Jeremy Miller from CodeBetter is a proponent of Unit Testing and Agile methods. He says in his Programming Manifesto:

"An axiom of software development is that problems are cheaper to fix the sooner that the problems are detected. If you take that axiom at face value, it's easy to see why I put far more weight into comprehensive test-first unit testing because it gives you far more rapid feedback to find problems fast. Small, isolated unit tests work on very granular pieces of the code, so the number of variables in any single unit test should be small (if it's not, look for a different way to write the code). You shouldn't even try to run the code as a whole until all the constituent pieces have been validated through unit tests."

This is very easy to build if you are starting a new project. What do you do if you have a large, enterprise-sized project that has no unit testing? You start out with your business layer and build from there. Start with a small method, then you can build up from each class.

I worry about trying to get the Lexus when I'm only looking to build a Kia. I want everything to be perfect when I've gotten something to the point of "release ready".

When Jeff Atwood (Coding Horror) started posted about formal unit tests, he was struggling to find the "perfect test":

"You'll get no argument from me on the fundamental value of unit testing. Even the most trivially basic unit test, as shown in the code sample above, is a huge step up from the testing most developers perform-- which is to say, most developers don't test at all! They key in a few values at random and click a few buttons. If they don't get any unhandled exceptions, that code is ready for QA!"

So I start by building small tests and work from there. It may take a long time to fully implement unit tests, but I believe this will be to our advantage in the end.

I offered this solution of adding unit tests and GUI automation to my boss. He seems to think that this will add significant time to programming and it won't be practical. The real problem that he doesn't trust that the interface will get a thorough testing. I told him that there are ways to get this working (possibly using InCisif or WatiN) that would be just like one of the QA team. He really just can't see how it will work for us.

I don't know how I can explain to him that it will end up in his best interest (and mine) to add the unit tests for the business layer and for the GUI. If not, I guess I'll just have to revert back to programming using BDD.

Stephen Wright : TDD

FitNesse with Bob Martin – Part 2

FitNesse with Bob Martin – Part 1

My Unit Testing Challenge