[LRUG] TDD (was: Ruby Contracting)

[Richard Patching]

I think you hit the nail on the head so-to-speak. Very insightful.

I personally have found learning to write good, valuable tests a lot  
more difficult then learning Ruby itself. I also found that writing  
tests helped me pick up the language a lot quicker then simply hacking  
around. The temptation was always to just jump in and starting writing  
code, because I was frustrated at how much writing test was slowing me  
down. This led to me writing bad, buggy code and having to come back  
time-and-time again just to fix things. Since I got into the habit of  
writing features and specs before actually touching any of the  
production code, my development time has increased dramatically. I  
feel more confident (not over-confident) in tackling problems, and  
that any refactoring or new feature is backed up with specs. If it  
breaks any of the existing code, i'll have a fairly good chance of  
picking up on it early on.

Learning a programming language is fairly easy. Learning to be a good  
programmer is a completely different thing. Methodologies and  
practices are there to help, knowing when its best to use them comes  
with experience. I've met plenty of people who have knowing  
programming languages inside out who I wouldn't count as great  
programmers. I have also met some developers who may not know it all,  
but know how to tackle a problem and which tools and practices to  
utilize. Much more valuable in my opinion.


>
>
> I think it would be hard to argue that all tests were actually  
> useful, and it's generally a good thing to ask when writing a test -  
> how much value is this test adding?
>
> A mistake that I made all-too-often when I was being schooled in TDD  
> was writing too many tests around implementation-specific classes,  
> and not enough that actually described the overall behaviour I  
> wanted - tests that describe the actual value of the feature I'm  
> working on, rather than those that crystalise the particular  
> architecture-du-jour. These days, I always try and start by writing  
> tests at the highest possible level to describe the behaviour I  
> want, and then as the internal APIs start to coalesce I can start to  
> look more that the 'unit' tests.
>
> It's possible to spend a lot of time testing every aspect of an  
> application at every level (individual classes and various levels of  
> integration), but I'd argue that not all of those tests are adding  
> the same amount of value. Perhaps a "good" TDD programmer can spot  
> which kinds of tests are the most valuable in a particular situation?
>
> Speaking of value - the real value of automated testing isn't  
> immediately realised; the payoff comes months later when you or  
> someone else needs to make a change but be relatively confident that  
> everything still works. Sure, you can use them to verify the method  
> you literally just wrote, but that's a trivial benefit for a  
> seasoned programmer. It's hugely tempting, particularly for those of  
> us who've been "programming forever", to feel like writing tests  
> just slows us down, and that our experience is enough to ensure that  
> the code matches our intention. This is arrogant folly for two  
> reasons:
>
> 1) It assumes that our intention matches the customers. Codifying  
> behaviour in high-level tests is a great way of making sure that  
> everyone has the same expectations, because good tests rarely talk  
> about the nitty-gritty nature of computing, but things like "If a  
> user signs up, they get an email with a confirmation link".
>
> 2) It assumes that we, the programmer, will always be able to keep  
> the entire system in our heads any time we need to work on the code.
>
> Writing good tests is hard, but without some form of regular  
> testing, there's simply no way to keep up velocity on a project.
>
> James
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org