Planning to test

Traffic Lights
Originally uploaded by Roo Reynolds

When I code, I want to have confidence that my code does what I'm intending, and not being the most self confident coder in the world, writing tests boosts my confidence (except when they all break). Part of this is writing tests that are true to life examples of how the system will be used.

I'm not quite on the test driven development bandwagon yet - I would love to be, but I think I need to be more disciplined to make it work, and really need to learn more about mocking - and properly interfacing out my objects.

For my projects there are a few types of test that I'll write:

• Integration tests that are testing a few components, for example creating a new object, validating the data and then saving to the database.
• Story based integration tests - usually testing the API or services that are available, ensuring they correctly accept data, validate, save and return.
• Simple database connectivity tests - to ensure my NHibernate mapping is correct.
• Unit tests to test a single method.

There is probably a wide range of scenarios that I'm not checking, which is where working with a tester to manually write up the scenarios and work through them really helps. Over the last couple of weeks I've been working with a colleague, and have found this to be really useful.

Now we've got into our 4th round of testing, and testing is really starting to become labor intensive, which brings me to the question of how do I automate all these tests? To me, I would be confident building the tests in code, but how do you help others build confidence in your coded tests?

How does traditional test planning fit into an agile type development project? As I've written a large number of tests, where does the need to manually test come in?

For the continuing development, testing will obviously need to continue, and we'll need to keep automated tests up to date, which is a subject for another post.

Pair programming

Originally uploaded by ThaRainbow.

A while ago my colleague and I started work on a new project so we decided to do some pair programming, which was the first time I had worked like this. My colleague, having worked with pairing before at a previous job, took the lead. We'd been talking about using agile methodologies for a while, and thought it was a good opportunity to have a go.

At first, it was pretty awkward, as neither of us were overly good at communicating our coding plans, so we'd often wait till the other nutted out a bit of an idea, and then talked it over. We tried writing tests first, which was pretty successful, but once again, trying to figure where the other was going was pretty hard work.

We only worked together for a few days, and then got split to work on separate projects, but I would love to try  it again.

A couple of things that I found:

• Pairing is humbling - if you don't know something, it becomes pretty obvious fast. 
• Ideas are up for grabs - no one is going to be right all the time - you've gotta be prepared to put your ideas out there, and be prepared to talk them over and admit that you aren't always right
• Great collaboration - although it's hard, it's a great way to learn and discuss ideas. It makes you work hard to communicate effectively - which is a great skill to generally have. 
• Promotes openness - I find the way I like to work is on my own, but being pushed to work with others and be transparent is quite liberating, and it means you aren't the one source of all information.

How do you go working with others? If it's software, have you tried paring? If you're not a developer, what are some ways that you've been forced to work with others that have been surprisingly beneficial?