Testing Frameworks (CDC,TDD & BDD)
The most natural approach to testing interfaces between provider and consumer is end-to-end testing. In end-to-end tests (E2E tests), real servers or containers are set up so that provider and consumer (and all other services they require as dependencies, such as databases) are available in a production-like runtime environment.
To execute our integration tests, the consumer is usually triggered by providing certain input in the user interface. The consumer then calls the provider and the test asserts (again in the UI) if the results meet the expectations defined in the contract.
Consumer Driven Contract Tests (CDC Tests)
The core idea behind CDC is that the service consumer defines the requirements for the service provider’s API. Each API user concludes a contract with the service provider laying out the requirements on the API.
Behaviour Driven Development, or BDD, is a branch of principles defined by Test Driven Development (TDD). In TDD, we build the thing right. In BDD, we ensure we build the right thing. The principles and technologies leveraged in BDD have been widely adopted in functional testing. A BDD testing framework includes the likes of Cucumber and SpecFlow, which have enabled non-technical product owners to define application behaviour as human-readable text. As those behaviours (or features) translate into test code, the QA team can achieve test automation faster and easier, even with a lack of domain knowledge.
But adopting BDD is not an overnight venture. The human-readable text must translate into code, and where there is code, there are developers. Typically that test library must be developed and maintained by developers or technical testers, This is where the BDD testing framework tools come into play to help save the day. To transition to the BDD framework, you can depend on functional test solutions that integrate with the BDD framework to assist in defining features.
Process Of BDD
The process involved in BDD methodology also consists of 6 steps and is very similar to that of TDD.
Write the behaviour of the application: The behaviour of an application is written in simple English like language by the product owner or the business analysts or QAs.
- Write the automated scripts: This simple English like language is then converted into programming tests.
Implement the functional code: The functional code underlying the behaviour is then implemented.
Check if the behaviour is successful: Run the behaviour and see if it is successful. If successful, move to the next behaviour otherwise fix the errors in the functional code to achieve the application behaviour.
Refactor or organize code: Refactor or organize your code to make it more readable and re-usable.
Repeat the steps 1-5 for new behaviour: Repeat the steps to implement more behaviours in your application.
BDD is considered a best practice when it comes to automated testing as it focuses on the behaviour of the application and not on thinking about the implementation of the code.
The behaviour of the application is the centre of focus in BDD and it forces the developers and testers to walk-in the customer’s shoes.
TDD is a development practice while BDD is a team methodology. In TDD, the developers write the tests while in BDD the automated specifications are created by users or testers (with developers wiring them to the code under test.) For small, co-located, developer-centric teams, TDD and BDD are effectively the same.
TDD methodology follows a very simple 6 step process.
Process Of TDD
- Write a test case: Based on the requirements, write an automated test case.
Run all the test cases: Run these automated test cases on the currently developed code.
- Develop the code for that test cases: If the test case fails, then, write the code to make that test-case work as expected.
Run test cases again: Run the test cases again and check if all the test cases developed so far are implemented.
Refactor your code: This is an optional step. However, it’s important to refactor your code to make it more readable and reusable.
Repeat the steps 1- 5 for new test cases: Repeat the cycle for the other test cases until all the test cases are implemented.
Key Points of TDD
The Process starts by writing a test case.
It focuses on how the functionality is implemented.
- Test cases are written in programming language.
- Changes in how the application functions impact a lot on the test cases in TDD.
- Collaboration is required only between the developers.
Might be a better approach for projects which involve API and third-party tools.
Key Points of BDD
- The process starts by writing a scenario as per the expected behavior.
BDD focuses on the behaviour of an application for the end user.
- Scenarios are more readable when compared to TDD as they are written in simple English format.
BDD scenarios are not much impacted by the functionality changes.
- Collaboration is required between all the stakeholders.
Might be a better approach for projects which are driven by user actions like e-commerce website, application system etc.