In skygate we use BDD. We have described how and the reason why.
tl;dr version. Early stage startups should use BDD by default. Perfect choice, fits all sizes.
Let’s recap what”BDD” means.
Instead of writing unit tests the goal of BDD is to create stories using a natural language non-programmers can easily read. It has its roots in Test-driven Development (TDD), but it focuses on how we expect the application to work – so on the behavior. The author of this methodology – Dan North said that in the several past years the definition of BDD has changed so we don’t want to describe another encyclopaedic description of this term but we will try to focus on our approach/understanding and application of BDD for early-stage startups.
Why in skygate we believe BDD (Behaviour Driven Development) is the best approach for early stage startups?
You are an expert of the business domain where you build the product. Developers are experts in technology and you probably don’t care. You see the product in terms of features, outcomes and value given for the end-users.
You are a startup – so the outcome – even if built correct – need to be validated by the market. Assuming you will be using the customer development methodology, so you’ve more or less proven the problem-solution fit and the product-market fit – in the early stage there will be a lot of space for small pivots and optimisation.
We really like the idea of writing the specs and applying tools that generate code snippets based on them. This is a place where code meets business requirements. Whenever a specific feature or user story is done – using tools like Behat (PHP) or Lettuce (Python) you can see the terminal/html output with information which user story is done and which should be completed.
When your startup is pivoting it’s often much easier to modify the user stories than rewrite dozens of unit tests.
What are user stories, scenarios and features in BDD?
In BDD, a developer or QA engineer might clarify the requirements by presenting specific examples, scenarios that are understandable for both developers and non-programmers.
An example of user story:
‘I feel tired and I think I need coffee to liven up. I want to do the following activities.’
GIVEN: I am in the kitchen When I put coffee beans to the coffee machine And I put cup to the feeder plate And I wait until led control will switch off And I take cup from feeder plate And I put 2 spoons of milk to the cup And I put 2 spoons of sugar to the cup And I drink the coffee Then I should feel the power
Each scenario is designed to illustrate a specific aspect of behaviour of the application. When discussing the scenarios, participants ask questions that can help to uncover further scenarios, which clarify the requirements.
What is TDD and what is the difference between BDD and TDD?
TDD stands for test-driven development and it relies on the repetition of a very short development cycle:- The developer writes an automated test case, failing at the beginning, (defining a desired improvement or new function)- Produces the minimum amount of code in order to pass that test↵- Refactors the new code to acceptable standards.
Unlike TDD, behavior-driven development is a software development process based on test-driven development and it aims to deliver “software that matters.”
The choice between TDD and BDD is a complicated one. It depends on an appropriate testing framework for your given target language, what your coworkers are comfortable with, and sometimes other factors.
In TDD, the tests are written by developers while in BDD the automated specifications are created by users or testers (with developers wiring them to the code under test.)
BDD deals easier with business concerns and allows to create tests that refer to User Stories criteria. This allows us to write software that shows exactly what our stakeholders want rather than writing code. BDD focuses on organizing the proper conversation between developers or testers unlike TDD that is focused on technical language. Tests when using TDD will be only helpful to one group of people able to understand everything like engineers for example.
To sum up, how do we solve the problem of buggy software being delivered to customers? By making sure that testing is not seen as something “only the developer care about”. If needs are clearly described and understood the process of further developing is a great way to achieve a good quality product.
Need experienced partner in BDD? Let’s talk firstname.lastname@example.org