Believe it or not, we’re trying to introduce BDD (Behavior Driven Development - http://en.wikipedia.org/wiki/Behavior-driven_development) using automated tests on the large web front-end implementation project (based on .NET and heavy JavaScript). And we’re doing it, because actually these are the client people who came to us and told us that they are more than willing to try explicitly that and they’ve already made first steps to do so. How awesome is that?

Some of the initial ideas were quite crazy (plenty of those just forced by the project reality), toolset choice is controversial (it’s an understatement ;)), but in the end they did really good job with not only covering a nice bunch of scenarios, but they’ve also created some kind of logical intermediate layer that provides the necessary abstraction that speeds up coding of particular scenarios and aids the maintenance of tests.

But even if work put into that is worth of the respect, the real struggle starts now - the key is not to create some tests, the true challenge lies within making them last and keep their value (quality and coverage):

tests that can’t be run by a developer (at least before each commit) don’t make sense

if developer isn’t responsible for test-covering the code he adds / changes, give it up