Test driven development vs Behavior driven development

Test driven development, as the name implies, is driven by a number of tests. After a unit test is written, it is then run against a code that is as yet unwritten. The tests naturally fail, and so the second task is to write code that allows the test to pass. The problem here is that the code itself is bound to be full of bugs – and when developers put their time into writing all kinds of test code without writing any production code, it comes across as a futile undertaking.

Suppose a unit test is written to test a new class, the tests assign a particular attribute to the class and attempt to mimic this attribute. In such cases, what is being tested is the capacity of the code to accept a given value and the likelihood of retrieving it. What is ultimately tested is the compiler or the interpreter – and so nothing of any substance is tested.

Yes, such code can perhaps advance into something more complicated, in which case that unit test code can help avoid regression. But, this usually doesn’t happen on a scale significant enough to justify the initial investment of time and money, and such far-reaching changes in any case would nullify the unit tests when more complex computations enter the scene.

No organization wants to waste resources, which is why it’s doubly important to assess when and for what purposes one should employ unit tests. Complete test-coverage is a needless burden. And the fundamental issue with this kind of development is that the developer, under perpetual time pressure, cannot realistically be expected to build a well-integrated product; it’s more likely that they’ll construct something for the purpose of doing, no more than just passing that particular test. Furthermore, this process tends to undermine talented developers, because anyone in possession of a code-editing platform can take on the role and do a poor job.

In making a system testable, developers consciously or unconsciously apply quite severe restrictions on the architecture, a measure that ends up over complicating the code and actually obstructs the problem-solving process for businesses. This approach could apply to very complex systems, but in a world where technologies and methods get outdated every few years, the long-term resilience of a given software architecture should not be a priority. What should matter in fact, is the accessibility of the current software and its delivery period.

A testing method, therefore, cannot demand the reconfiguration of stable architecture. And this is exactly what test driven development demands, which makes it inefficient and in need of replacement by a more appropriate, relevant, and modern alternative. This is where the Behavior driven development comes in.

This method starts in the same way as its ancestor (defining the tests that need to be passed), but devotes more attention to a system’s overall functionality instead of the details of its primary construction. It also closes the gap between developers and users by operating on an easy-to-learn language called Gherkin.

Essentially, if one shifts from the test-driven to the behavior-driven development, one can divert one’s attention away from the actual tests to the requirements of the application, and focus on making sure that the behavior of the app conforms to these specific requirements.

But the decision of which method to use comes down to the nature of your framework and your target language. And even though the behavior-driven development can prevent issues, its success is not guaranteed in this regard. Poorly written code and outdated design practices cannot be eliminated altogether, but the likelihood of writing buggy tests is admittedly lower.