Showing posts with label AltNetUK. Show all posts
Showing posts with label AltNetUK. Show all posts

Monday, February 04, 2008

Developer Testing - Discussion at ALT.NET UK

I thought I'd blog about some of the topics that were discussed at ALT.NET UK, or more correctly my views on those topics.

Styles Of Testing

I've blogged about the fact that I tend not to use interaction testing much. I find interaction testing can result in overspecified software and sometimes in tests that are hard to read. To be fair some of this could be countered by better use of mocking, for example diffrentiating between mocks and stubs (or Stubs and Expecations if thats the terminology you prefer), but state based testing is still my preferred approach especially for the domain model.

In the disucssion of mocking at ALT.NET UK it seemed that most of the attendees agreed that we are now overusing mocking. Whilst there was little disagreement with the idea of stubbing/mocking in some situations (e.g. between layers or domain modules) most people did seem to think it was dangerous if not used carefully.

Ian Cooper has blogged about this topic too.

Granularity

What granularity to test at, something that constantly irks me. To some people unit testing is always testing a single class, I've always thought that you can use unit tests for (small) groups of classes. In particular I do this when I have a helper class that I've extracted out of the class I was previously testing.

There are advantages and disadvantages to testing groups of closely related classes together though. The main advantage (especially early in design) is the tests can withstand refactoring and the main disadvantages are that they can be more complex and don't have such good defect localization.

Anyway Ian Coopers blog entry sum up my views on this entire topic. We also discussed whether to move/copy the tests down to the extracted class when you use extract class refactoring.

I'm totally inconsistent on this, I sometimes test against the extracted class and sometimes leave the tests at the level of the class I extracted it from.

Design For Test or Design For Design

The topic of design for testability came up a lot, though not in the way you might expect!

I've never believed design for testability is necessarily a good idea, I've blogged about this topic in a couple of posts before including here and here.

I don't believe there is any good substitute for thinking about your design. Sometimes designing for testability, especially if you favor lots of mocking using a traditional mocking tool, does bring lots of decoupling it's not necessarily as good as focussed decoupling.

Anyway I knew Roy Osherove was no longer recommending designing for testability and so was expecting a lot of disagreements around this topic. In actual fact though there wasn't much disagreement on the topic.

End To End Testing

At one session Tana Isaac discussed Watin which can be used to write tests for your GUI. The discussion covered whether GUI testing is a good idea because it can be more trouble than it's worth. However Tana pointed out that the tests they are writing are not only acting as good specifications but are not at all flakey and indeed are rarely being modified.

Others also mentioned the Web testing functionality in VS 2008, which apparently is far better than what was in previous versions.

The general discussion fitted in with the contributions that Nat Pryce made to an interesting TDD thread. Nat sums up the way he tests in this post.

All in all myself and John both came away thinking that we needed to look more at Watin and end-to-end testing in general.

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone

BDD - I think I'm finally getting some understanding

Nick Hines from Thoughtworks led a really good session on BDD at ALT.NET UK. The session clarified a lot of things for me, though as always after a bit of thought I am left with plenty more questions so I thought a blog entry was in order.

What Is BDD
My initial experience with BDD was Dave Astels doing a videocast about it. Better TDD and focussing on design were the name of the game. This made sense but when I started looking into it more I got a bit lost. The documentation seems to focus on the influence of DDD and the use of interaction testing. This confused me a bit as unless you practice need-driven development its questionable whether you are using interaction design as a domain design technique. I was also confused as to how BDD fit in with DDD, other than both sharing the idea of a ubiquitous language.

Anyway the discussion clarified the fact that its fair to view BDD as better TDD and it has little to do with need-driven development (though I guess you could use them together). It also doesn't specify that you must be using interaction testing.

Where to use BDD
We also came to the conclusion that these tests were quite high level, more influenced by users (user story acceptance tests) or a business analyst. I'm thus not clear that they would influence the domain design other than at a shallow level as your users are normally not your domain experts. This is probably what Greg Young means when he talks about BDD being used to for a shared language which may be distinct from the ubiquitous language.

Practically this probably means writing these tests against high level domain entities or your application/service layer. The discussion did cover whether you then take the BDD tests into the domain and indeed right down to hidden implementation details. I'm still not clear on this but if we are using BDD tests as specifications then starting out with detailed high level specifications isn't a bad idea, it gives us a good way of specifying acceptance criteria.

More Questions
The question is then how detailed to make these high level BDD tests. They have to be quite detailed and comprehensive if they are acceptance tests but if you make them too comprehensive then you are going to end up testing the same things at multiple levels, initially with a high level BDD test then with more detailed "unit" tests.

This seems attractive to me though, Jimmy Bogard has a great post about how he tried to make sure his BDD tests are somewhat immume to refactoring (changing implementation).

Other Links
Ray Houston is one of many people blogging about learning BDD, including this really interesting post.

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone