The speaker basically says, if you already do Test Driven Development, then you're well on the way to doing Behaviour Driven Development. This seems to be mainly a vocabulary change, according to the speaker. He talks a lot about the specification and design elements of TDD; in particular, he's of the group that advocates TDD as a design methodology, with no thought of "testing" whatsoever. I think I'm starting to become an advocate of a "truer" Test-driven approach at this point. I think that there needs to be a level of acceptance of responsibility for functional testing by programmers, and it's not exactly hard to do for the scale of system I tend to work on. I'm sure for the 20-bazillion-line systems it's a very different exercise, but for 200k or so lines of code, it's really not that hard to at least start to putting some basic automatic verification into the development pipe.
As a process guy I'm putting Acceptance Tests
into the TDD pipe, because I think that they belong there. Anyone who has done any serious amount of TDD probably has discovered that Unit Tests are very seldom sufficient for verifying a system. You end up having to create tests that go end-to-end to make sure that even the simplest shit doesn't go wrong and isn't forgotten - if you refuse to access a database in your units (which is quite common amongst practitioners), for example, then you have some problems in designing a test for scenarios where a user does some work in the app, saves, shuts down, and then re-loads from the last point of work. The end-to-end test at least requires that that entire sequence is run once.
It's actually kind of surprising to realize how few Acceptance Tests are required to get plenty of Code Coverage
, at least in the line coverage
sense. I realized this back when I was doing integration work, but it is particularly relevant now that I am working almost full-time on the problem of making a simple, useful process for everyday development. Acceptance Tests are primarily useful rather than simple, and I don't really write a lot of them, because they tend to be motherfuckers, pardon my French, and require waaaaay too much setup work. I'm starting to learn about things that might make my life easier in that respect (round-trip
rather than front-to-back testing, for example), but I'm not sure how practical they will be when every system I work on has integration requirements as well as core system requirements.
Side note: Although I haven't used it yet, Jester
(or, for C#, Nester
) sounds extremely cool and useful for code coverage checking. The Nester author talks about leveraging NCover
to decide which code is actually covered by tests to begin with, to avoid unnecessary permutation of code, since permutation is a large performance hit. I get the sense that Nester would best be used on a low-frequency basis rather than for Continuous Integration
, perhaps only over the weekend for a typical enterprise app.
I'm maybe three quarters complete on my curriculum for TDD. Although I haven't actually read the book yet, I get the sense that it's largely a compression of Kent Beck's book
. I've got that book on order, although I haven't exactly been good about reading my books lately. Having a bunch of books come all at once was a godsend in that I could really leverage other people's knowledge, but it was a bit painful to try to deal with the information overload that came out of it. I can't recommend Working Effectively with Legacy Code
strongly enough, however. I've read bits and pieces from every part of the book, and I leave it open and in front of me all day at work. It's pretty limitlessly useful. The worst thing I could say about it might be that it's a paperback book, but that's not exactly a big deal for the time being.
On a different note, I've been looking at Version Control over the last couple of days, for no better reason than I want to know what we're missing, and it would appear that there are a couple of cool tools that might be fun to play with. In particular I want to try:
- Mercurial - this is designed for managing large distributed projects, but it does some fun stuff that may be worth looking at for use as a personal source controller as well.
- Darcs - seems like most people who talk about this have a great deal of respect for it, but only as a theoretical playground. I'd like to get a sense of what it does nicely and whether it's better in some respects than other DVCSs.
I'll probably also take a look at Perforce
(with or without SVK
), but there's only so much time in the day. I would like to have something to use as a source manager for a couple of projects that may or may not become large as time goes by.