The BDD Extension Framework in details: What are we going to learn

Here there is a list of questions and answers that will explain the most common doubts about the automated tests, the Behaviour Driven Development, the use of the BDD Framework in Unity and the best practices for testing the software using this framework. This guide covers just the aspects of the BDD relating the coding.


Q: What are the differences with the old manual testing approach?

The manual test method forces the developer and the tester to interact with the software using their hands and their eyes to verify the software behaviour. This type of test takes an enormous amount of time and, unless there is a written list of tests to execute, covers only a little part of the tests the software should need. For assuring the complete absence of errors, ideally, all the tests have to be done for each change of the code.

Using a framework that lets you automate the testing process help you to run the tests in a faster way and, most important, there is not the temptation to skip some planned test for lack of time.

One of the most important differences is the possibility to code your software using the Behaviour Driven Development approach.

The Unity Test Tools give you the right instruments to automate your tests.

The BDD Extension Framework for Unity Test Tools gives you to the right tool to develop using the Behaviour Driven Development approach and to formalise your tests in a more readable way.


Q: This is not Unity Test Tools. What is the difference?

The BDD Extension Framework is an Extension of the standard Unity Test Tools. It uses them and gives to you an additional way to develop and run your tests. The presence of the Unity Test Tools Asset in your

project beside the BDD Extension asset is essential.

This extension allows you to use the Given-When-Then scenarios, particularly used in the Agile Development Processes. It lets you write down your automated integration tests in a more readable form. They are particularly useful when you have to understand the tests coverage or to understand what the test is going to verify, especially when it fails. You could already meet the Given-When-Then scenarios if you have used software like SpecFlow, Cucumber or Selenium.


Q: Can I continue to use the Unity Test Tools?

This framework extends the Unity Test Tools Integration Tests. That means you will continue to use the Unity Test Tools but in a newer and simpler way. You will still able to develop your integration tests in the standard way.


Q: I do not follow any Agile Framework, I do not use User Stories, and I barely understand what they are. Is that a problem?

If you don’t work in an agile environment, you could not be used to the concept of the User Stories. Using BDD is not directly related to the User Stories, even if it is more natural to develop using BDD if you work under a user story. In this guideline, we try to not bind the concepts to any Agile Framework and User Stories. Instead, if you work in an agile environment and you are using the User Stories all the time you will be able to make the right equivalences between the “requirements” of the software and the user stories.


Q: I read about Acceptance Tests, Integration Tests, Regression Tests but I don’t know what they are. Could you explain them?

  • Acceptance Tests are written to assure to meet the software requirements. For example, if in your software an object has to move to a specific position after touching another object, you code your test to verify this behaviour.
  • Integration Tests are written to assure that your different modules in development for your software are running correctly together.
  • Regression Tests are written to assure that all the changes made on the software are still compatible with the other parts of the software or, in general, to verify the software behaviour after the changes.

One of the most frequent questions from the developers about these types of tests is: How can I recognise if a test is an Acceptance Test, an Integration Test or a Regression test reading the code?

The answer is: Usually you can't. The difference is regarding the scope of the test. You can sense if the test is one of them reading its description, but after its development, it has the same form of the other types of test.

There are several ways to code them. BDD Extension Framework helps you to write and maintain all these kinds of tests using the Given-When-Then scenarios.


Q: I don’t know anything about Given-When-Then scenarios. Can you explain me those in detail?

Given-When-Then scenario is a method of proven efficiency for describing the software behaviour, given a previous state and an action. It is based on three steps:

  • Given: The description of the software state at the beginning of the test.
  • When: The description of the action that has to occur on the software.
  • Then: The description of the expected behaviour of the software.

Describing a scenario using this format has the following benefits:

  • It helps the user, the analyst, the stakeholder, the product manager to describe the tests in a more efficient and clear way.
  • It helps the developer to understand easily the scope of the test you are going to code.
  • It contributes to maintaining the readability of the test: after its development, you can understand its scope easily.

An example of a Given-When-Test scenario is:

  • Given I am on the first page of the control panel of my software
  • When I click on the “Back” button
  • Then the software has to close the control panel.

As you can see, the first sentence “Given I am on the first page of the control panel of my software” gives you the state of the software before the action you have to test.

The second sentence “When I click on the “Back” button.” is the description of the action you have to perform to obtain a result to test.

The third sentence “Then the software has to close the control panel.” is the expected behaviour.

One of the most frequent questions is: This test seems to be incomplete because it does not say what has to appear after the software closes the control panel. The answer to this question is pretty simple: there will be other scenarios that will describe what the software has to show after closing the control panel. The behaviour could change depending on the initial state. In our example, the description of the initial state of the software does not mention anything about what the software showed before opening the control panel. It means that every time I am on the control panel, and I click on the back button, the software has to close the control panel, with no exceptions.

One of the most frequent problems for the developers for understanding the Given-When-Then scenarios is to understand the association from the description of a scenario and the actual code that tests it. The explanation of this concern is: some frameworks associate the Given-When-Then sentences to the code you have to write. The BDD Extension is one of them, specific for Unity.


Q: Are there some guidelines for developing using BDD?

You can read the section BDD Extension Framework Guidelines. However, there are some rules (among the others) you have to know right now to understand correctly what are you going to learn:

  • Test First - Code After principle: The Behaviour Driven Development is based on this principle. It means that you are going to write and code the test before you develop the code you need to test.
  • Test only a single behaviour at a time: Each test should verify just one behaviour. If you test more than one behaviour at a time, you could bind these behaviours to each other.
  • Develop just what is strictly necessary to pass the test: Developing some extra code could indicate an over design of your software.
  • Do not insert extraneous code during your coding: If you put just a line in your code that is not specifically requested by the test scenario, that line could stay not tested until you release your software.


Q: I am already using TDD. Can I continue to use it?

TDD stands for Test Driven Development, and it is based on the unit tests. BDD stands for Behaviour Driven Development, and it is based on the Unity Integration Tests. They are not exclusive. Actually, they are complementary. The Behavior Driven Development approach allows you to design your software from a higher point of view. Using it, you will design your classes closer to their natural use. However, when you are developing your classes in a higher detail, the TDD process will help you to focus your effort only on what you really need to develop.


Q: Am I forced to do TDD also?

You are free to develop your software in the ways you are more comfortable. However, if you are thinking to use BDD, it could mean that you are looking for a more efficient, organised and clear way to develop your software so that TDD could be the natural addition to your development process.


Q: Are the examples developed using TDD?

For simplicity, the examples are not developed using TDD. It is intentional: we did not want to overload the explanation with other concepts that might confuse you.


Q: I want to increase the test coverage of my software. Could BDD help me?

Of course! BDD and TDD follow the principle “Test it first”. It means that before you start to write down your code, you write the tests that verify the code you are going to write. If you follow this approach strictly, it lets you have only code already tested.


Q: The tests written using BDD are enough to consider my software completely tested?

The answer is: usually they are not. It depends on how much detailed they are. During a BDD session normally, you develop the tests that verify the user requirements and the acceptance criteria. Sometimes they could also involve the coding of the Integration Tests. Usually, they do not include the Regression Tests. You should code them at a later stage.

If we have to talk about a complete test coverage, we have to consider a lot of other aspects, like the behaviour of your software on particular devices or circumstances. In large enterprises, there is usually a separate team called Quality Assurance Team (QA): the members of this team have the right expertise to analyse and prepare the automated tests for cover those other aspects of the software testing.


Q: I have already a software. Can I start to use the BDD Extension Framework on it?

You can use the BDD Extension in more than one way. It is a bit late to develop in BDD for the code you have already written unless you are going to rewrite it. However, you can use BDD for writing the new code for your software, adding, for example, new features. However, other than that you are still able to write the Acceptance Tests, Integration Tests and Regression Tests also on the code you have already written.


Back to: The BDD Extension Runner options Read next: Getting started


© 2017 Hud Dimension. All Rights Reserved.