We’re still bad at this and tend to lean toward both developers writing acceptance tests and acceptance tests are coded after the unit tests. I know, bad Ian no biscuit.
We have never really got on with FIT. The idea, that we have a format we can exchange tests descriptions with customers in, is great, but the implementation is clunky and constrained. We have tended to rely on homebrew front ends that exercise specific scenarios, calling into our back-end. Similar in principles to FIT, but different in execution. But that can add a lot of effort. So I’m more and more interested in some of the tools emerging from BDD like NBehave as they, to me, seem to be a better way of expressing the acceptance test requirements.
Greg Young had an interesting post recently about the relationship between BDD and DDDs ubiquitous language btw and particularly the danger that BDD may inhibit the formation of DDD’s ubiquitous language because communication about the model is expressed via BDD’s abstraction and not the shared abstraction of the domain. Food for thought, though I’m not sure that we do not actually have two distinct domain languages in play: one concerned with how we validate the other.