Thursday, September 24, 2009

TDD Mind Shift

Ok so I am not the fastest adopter, however recent situations have almost forced me into a new way of thinking. Recently I was going over a fellow colleagues code and was about to add a test to one of his existing fixtures. He had previously mentioned that he felt there were a lot of tests, I told him not to worry, often when you are new to TDD it seems like a lot of extra code... I had underestimated his comments, he was right there was a ton of tests, thousands upon thousands of lines of tests, in one fixture.  I had clearly not been doing my job and should have been helping him out.

The test were broken down into one fixture per class under test, using regions to separate out test groupings, typically for each method under test. There was some very basic common set up however there was still a lot of set up in each test. It became quite clear that there were certain common set ups that were occurring.  Although the test per class is common it is usually not the best way of keeping your tests together, especially if you are being thorough in your testing. What my refactoring produced was akin to something I have been following for awhile but not really embraced, context based tests.  The tests were broken up so those with common set ups were grouped in their own fixtures; i.e. those with the same defined stubs. Although in this case it was done to make maintenance easier it highlighted for me the benefits of this approach.

Fixtures become specific to the context in which they apply, not blindly and solely to the class they are testing. This will lead to lead to multiple test fixtures per class and multiple test fixtures per method. This is what initially turned me off the approach; fixtures would be come to fine grained, however I have changed tact. Although it may not always be appropriate I can see it being beneficial for many situations. For example you may emulate the Repository having no records in it (via a stubbed method call) and run a bunch of test with that context. This encourages you to test not just method calls but to think it terms of a given scenario, something that I see unit sometimes missing in the pursuit of just achieving code coverage. The fixture tend to have test that are very small and very clear as to what they are asserting, often only a couple of lines per test.

Another thing that originally put me off the notion of Context specification and BDD was the perception of tooling... RSpec etc are not required, it is the thought patterns that I think are more important. Setting up a specification can be done using basic setup method with each fixture defining a specific context. Test inheritance can be very helpful here too.

Although Context specification and BDD are not the same thing I believe they are a movement in  the same direction; moving away for blind testing to defining scenarios that we need to test. Test become closer to one of the goals of being "readable documentation".

If you do what to read up a bit more check out:

Article introducing BDD styled tests with the notion of Context Specifications : http://www.code-magazine.com/article.aspx?quickid=0805061&page=1

A nice coding example showing one way of thinking in a context spec way: http://www.lostechies.com/blogs/rssvihla/archive/2009/05/21/context-spec-style-testing-and-my-approach-to-bdd.aspx

MSpec with Boo looks to be very cool too: (requires git client): http://github.com/olsonjeffery/machine.specifications.boo

Although the shift for me has not been great it has been significant, I would encourage you to at least investigate to consider if some of the principles can be applied in your testing.

Tuesday, September 15, 2009

When Easier is Better

Most of the people I currently or have worked with know that I have a strong preference for NHibernate for my persistence mechanism. I typically use a repository pattern, often with services hiding the repositories from the outside world. This is great as I get enterprise scalable domain-driven solutions up and running pretty quick and helps me focus on fixing business problem, not spinning my wheels with infrastructure details. However some time having DTO's, services, repositories, mapping files, anti-corruption/translation layers etc are just overkill. This is where is would typically say "Use Linq2Sql", if someone asked me what they should use, but its probably not what I would use. I like the idea of having the flexibility of moving from a simple domain to a complex domain with out too much problem. Enter Castle Active Record

Active record is in no way a new concept (PEAA p160) but is heavily under used in the .Net realm. AR is a great pattern when you are fleshing out a domain. You can very quickly start building up relationships have screens up and running for client very quickly. This is great for spikes but also for writing real code. The database can be generated from the code (Castle AR sits on top of NHibernate) so it is a great fix for fast moving agile project, especially in the initial sprints. The thing I like most about it is that if I decide I want a more complex domain, all is not lost; I remove the Castle attributes and references wrap a repository pattern around it and I am done. It really is that easy. All my existing domain unit tests should still pass. In a matter of hours you could switch from a developed 2 tier app to an enterprise ready scalable architecture.

Basically AR is great if you are lazy (or need results now).

To prove all of this I plan on presenting Castle AR in an up coming Perth Alt.Net meeting. Originally I had wanted to show NHibernate however I think the progression from AR to NH will help show both of there benefits. This may also allow us to show the limits of both... time will tell.

As a side note the castle stack (as well as NHibernate) has had a "proper" release this year so if you haven't had a look in a while check it out : http://www.castleproject.org/castle/download.html

Links - Articles

http://www.castleproject.org/ActiveRecord/gettingstarted/index.html

All you wanted to know about Castle ActiveRecord - Part I

All you wanted to know about Castle ActiveRecord - Part II

Links - Videos

Ayende Rahien - Using Active Record to write less code (Oredev 2008) << Watch me I'm great!

Ayende & Hammet - Painless Persistence with Castle ActiveRecord (JAOO)

Tuesday, September 1, 2009

The Build XML Divorce - Part II

OK, so as I continue to play with Rake I am very quickly seeing what is happening. I am in effect building up a bunch of reusable scripts that can manage task dependencies but really are just orchestrating other applications and system admin tasks. The syntax is nice, Ruby is a very clean fluent  language, however it is becoming abundantly clear that all I am really doing I reorganising my build flow from PowerShell and MSBuild to Rake and MSBuild... It quickly dawns on me that I probably have not understood how PSake really works. I have briefly looked into PSake only because James Kovacs (who I hold in very high regard) was the author. I quickly pushed it to the back of my to do list as it look more like a pet project that's only intention was to add to the variants of Make. The problem was I didn't really understand what it was supposed to do. At the time, in my mind all PSake provided was a means to have dependant task hierarchy written in PowerShell... that's it... buts that's all it needs to be! It should be calling out to MSBuild or csc.exe to build assemblies, it should be calling out to your test runners and analysis tools. The (R/B/M/Ps)ake tool is (IMCO) just a way to facilitate tasks and control their dependencies.

Ok so why the big rant? Well it was becoming obvious to me that what I was trying to do things in Rake last night were things that I could easily do in PowerShell. Not only easily but arguably much more appropriate to be done in PowerShell; things like file and directory manipulations. My build process is really pretty basic and can been done completely in an XML based tool like Nant or MSBuild. Its what I do after the most rudimentary clean/build/test that requires a bit more muscle, this is where I have been using PowerShell any way, so using PSake just makes sense. PSake is just PowerShell with a nice clean API to declare tasks with dependencies. Anything you can do in PowerShell you can do in PSake.

This is good news. So the next step is to refactor my PowerShell bootstrapper scripts into PSake tasks, pull some of my MSBuild task into PSake task and keep the MSBuild file down to the bare minimum that MSBuild does well.. namely: Build. One thing that I would have thought 6 months ago was that Rake/Ruby would soooo much cleaner sexier code... but no, I actually think the PowerShell code is very nice and very well suited to these types of task. Sure its got a few bugs to iron out, but my affection for PowerShell continues.

Sorry Rake, its been a fun 3 days, but its over... its not you, its me.