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
- if running tests impairs developer’s focus (for instance - due to execution time), say bye to the productivity
- if test results are not repeatable on the same code-base, you’re doing something terribly wrong
Two largest challenges we’re going to face right now is:
- making developers treat writing tests as the integral part of writing code (it’s more a mental change than a technical one)
- making sure that running front-end based tests run as quickly as possible (using all the tricks we have available)
Keep the fingers crossed, we’re doing something memorable here :)
