Ramblings of an Agile Padawan

I am working on an Intro to TDD hands-on workshop, so I created a project and started to go through and complete the user stories using Test-Driven Development to make sure there weren’t any major gotchas or anything silly or anything I missed. I thought that this would be a great time to share what steps I took. The project is for a bank account.

If you are not familiar with TDD, you can check out the webinar series here.  Or, wait for the class to become available to the public.

I got started with an empty project. I went ahead and added my code to Surround SCM and set up Hudson for continuous integration. I am using csUnit 2.6 for my unit tests. Time to get started.

Remember the goal of TDD is do as little as possible to get the test to pass (and not break any other test).

The first user story is: As a user, when I open an account, the initial balance should be zero so that I can start fresh.

My first task was to create a test that creates an account and ensures the balance is indeed zero.

[Test]

public void testInitialBalanceZero()

{

BankAccount account = new BankAccount();

Assert.Equals(0,account.getBalance());

}

Because there is no BankAccount class yet, this fails.

error CS0246: The type or namespace name ‘BankAccount’ could not be found (are you missing a using directive or an assembly reference?)

Now I need to resolve the errors. First, I create a BankAccount class.

The latest error is:

error CS0117: ‘Project.BankAccount’ does not contain a definition for ‘getBalance’

I right-click on getBalance() and generate a method stub. The method stub that Visual Studio gives me looks like this:

internal double getBalance()

{

throw new Exception(“The method or operation is not implemented.”);

}

Now my code builds successfully. One hurdle overcome.

========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

But my test fails!

I update the getBalance method:

internal double getBalance()

{

return 0;

}

SUCCESS!

TDD might be slower at first, but the more practice that you have, the better you get, and the faster it goes!

For the TDD hands-on workshop, participants are going to be coding an actual project in order to practice. One thing that seems to take a different mindset is that your goal should really be to do the absolute minimum possible to get the job done.

You write the test. If the code doesn’t compile (and that’s ok) change the code just enough to compile, verify the test fails, change the code just enough so the test passes, verify the test passes, verify all tests pass, and finally look to see if you need to refactor. Theoretically, you could refactor while in the process of changing the code, but it’s preferable to refactor on all-green when all of your tests are passing.

It’s hard to follow this process. It seems silly to start out with writing a test that you know will fail, and might not even compile.

Here is where we could all learn a lesson from our children. I know when I tell my daughter to clean her room that she is going to do the minimum amount possible to get the job done. First, she moves her dirty clothes from the floor to the hamper and runs her test. “Mom, I’m done.” (Actually she really tries to avoid running the test and prefers me not check to make sure it’s clean at all, but that’s another story altogether). I check her room, and say, “Seriously? You have dirty dishes and empty wrappers on your dresser.” (Which is awesome since she’s not supposed to eat in her room anyway). She then throws away the wrappers and puts the dishes in the sink (since I haven’t specifically told her to put them in the dishwasher, you know they are going into the sink). “Done.” I check again, “Seriously, your closet is so full of stuff it doesn’t close.” So she cleans out the closet. “Done.” I check again. This time, I may or may not remember to check under the bed. Actually, I don’t always insist that the closet door closes. Yes, she could’ve just cleaned the whole room top to bottom, dusted and vacuumed from the get go.  But then she might’ve done work that wasn’t absolutely necessary.

In the coding world, this might lead to dead, untested code. It will definitely lead to more code. The more code that you have, the inherently harder it is to maintain and the more bugs that you might have.

So, just do the minimum amount possible to make the tests pass.

Yes, that's a bean bag chair on the unmade bed.

Here at Seapine, we are introducing a couple of Agile Essentials classes. The first one, Agile Essentials for Project Teams , goes over Agile basics. It’s a two day course, and includes quite a few fun and enlightening activities. No one will be falling asleep during this class!

Alan Bustamante is heading this one up for now, and he’s taking it on the road to the earlier initial participants later this month. I am piloting an Intro to TDD course as well. Right now, I’m testing we are piloting it for on our internal guinea pigs, but hope to have it go public soon!

I’m very excited about Agile 2011. I was a reviewer for the QA and Testing stage so I had access to a sneak peak at the presentations, and it looks like it’s going to be a great week. Seapine will have a booth where we’ll debuting our great new Agile tools for TestTrack. If you are going to Agile 2011, make sure that you come say hi and check out our new app!

I recently joined Facebook because my 11-year-old daughter wanted to join, and I need a way to keep track of what she’s doing without being so dictatorial that I force her to cough up her password. (I, being a techie, was appalled by the lack of privacy and the fact that they added new ‘features’ that were opt-out without notifying their users and so refused to jump on the bandwagon). So, anyway, on Facebook there’s a spot to put in the languages you know, and I was really really tempted to put C++, C#, Java, Perl…(you get the drift) as my languages, thus total identifying myself as a geek to the online world. Since I required my daughter to be friends with me, she was mortified at the thought of her friends seeing this, and insisted that I not embarrass her on purpose.

I was telling this story to one of my friends, who is on Facebook and is now my Facebook friend as well (and agreed that it would indeed be embarrassing to her if she had a friend with computer languages listed), and she questioned me on what the difference was between the different languages and why on earth there are so many. She is totally non-technical (delivers mail) so I kept the explanation brief (sometimes your code will be data-driven and sometimes it will be process driven, and people can make money if they can get everyone to adopt their cool new language). As I was explaining the differences to her, the thought occurred to me of how hard it was to do TDD in C++ compared to how easy the instructors at my CSD class made it look and how easy it seemed in the class (Java).

I’ve been developing with C++ in Visual Studio 2005 for a number of years.  When I started doing TDD after the CSD class, I was hindered by the fact that there’s no support for refactoring. Visual Studio has refactoring support for C#, and I think that there’s an addin for VB, but nothing for C++. I did a bit of searching, and it looks like type-based binding is the reason why – you can read about it here.

Since I’ve moved to Services/Agile Services, my development is done mostly in C# (since it’s mostly to customize TestTrack using SOAP scripts). What I’ve found is that life is MUCH easier refactoring in a language/tool combo that provides some support instead of doing it manually!

With a name like ‘Ramblings of an Agile Padawan’, I just had to…my favorite.

I find that there’s a lot of discussion to be had about what the difference between Agile and Waterfall really is. According to Wikipedia, Agile is software development based on iterative and incremental design (http://en.wikipedia.org/wiki/Agile_software_development). Waterfall is a sequential design process, where progress flows downwards through phases (http://en.wikipedia.org/wiki/Waterfall_software_development).

I’d say that the biggest difference is when the design work is done, and when you get feedback. In Waterfall, you have a BDUF (Big Design Up Front), but you get feedback during the QA/Verification phase, which is almost at the end of the project. Agile is exactly the opposite.  Design is postponed until the very last possible moment (Just In Time), while feedback is solicited as soon as possible. Using Agile, you can adapt to change.

Even if you follow some Agile practices – unit testing, test driven development, pair programming, stand up meetings, etc., if you design first in the project and test at the end of the project, then you are not Agile.