Reading Time 4 minutes
What is the best approach of writing tests?
TDD vs BDD. Have you heard of either Test Driven Developer (TDD) or Behivour Driven Development (BDD)? These are perhaps the most common and most used practices when it comes to writing tests. Firstly, let’s discuss why anyone would want to follow a testing practice. Why not just write tests in whatever manner you want?
To Practice or Not To Practice
Let’s assume you do not follow any practices or principle. This means you are probably very happy about your tests, assuming they run and pass. Let’s also assume no one else will ever have to maintain your tests.
Now let’s assume you don’t touch your tests for six months, there is a good chance you will not be able to understand your own code. This is because the approach you toke was a very ‘in the moment’ approach. This sort of approach can be very fragile.
On the other hand, let’s assume you did follow some principle or structure that is well known in the software industry. Since your following a universal language, there is a good chance that you and others will be able to read and understand the structure and purpose of your tests.
Following a test principle means that we can maintain structure, formula and purpose of a test. It means we can give reason and purpose to a test.
What is TDD?
TDD is the practice of writing a test before writing the implementation code. We write the test and run it expecting the test to fail. The reason the test would fail is because the requirement the test is checking for does not exist. Once the implementation has been written, re-running the test should now result in the test passing. Writing a test before writing the implementation code, this practice is TDD.
Enforcing TDD into your testing process makes it easy to establish what the requirements are. You can easily capture requirements in the form of tests. The tests can also act as a exit criteria for any given task. Also, if TDD was followed throughout a project, if a test fails then this would be the same as saying that a requirement has failed.
What is BDD?
TDD was invented to help capture and manage requirements however TDD tests were designed to be written as low level tests. For instance Unit and Integration tests are low level tests. With TDD, this still did not help anyone other than developers understand what the captured requirements are. This is because low level tests were understood by developers, not Product Owners (PO) or Business Analysts (BA). This is where BDD steps in.
BDD tests are essentially ‘English’ friendly scripts which can be written by anyone using Gherkin. Gherkin is a very simple language which can be used to express a scenario. For instance:
Given <a condition> When <an action or event happens> Then <expect a response>
The above is a simple view of what a Gherkin scenario would look like, scenarios such as this can be written by anyone with any technical ability. Let’s enhance the above scenario a little:
Given I am on the login page When I enter valid logic credentials and press the login button Then I should land on the accounts page
It should be clear that the above scenario can be written and understood by anyone. The requirements captured in the scenario above can also be shared with anyone.
The biggest benefits of BDD is to help bridge the gap of technical abilities between a BA, PO and Developer.
TDD vs BDD
TDD vs BDD. Clearly, TDD and BDD are both great techniques to incorporate into your testing process as they both bring different benefits. One allows you to capture the requirements in tests before writing any code and the other helps to universally broadcast understanding. They both help to maintain tests and testing requirements The biggest benefits one can gain from these process is to use them both together.
In a given project, the BA would write stories or tasks in a Task Tracking tool for teams of developers to pick up. This usually translates into tests written by developers. On the other hand, if BDD tests were written by a BA before any code was implemented, this would follow both BDD and TDD. Ideally, writing high level tests before writing any implementation code should clearly give all team members the expected behavior to be implemented.
TDD vs BDD is a very wrong assumption. Both of these concepts should not be seen as competing factors, instead they should be seen as factors which compliment each other.