Many of us struggle to understand the different philosophies of development. There are quite a few ways to develop software in the market today. As a testing professional this is important for me so this is my take from my experience on this topic.
Test Driven Development (TDD)
This is perhaps the oldest of the method here and was developed in the late 1990s.
Unit Testing is the driving force here. Rather than writing the code and then testing, first it is tested. This will obviously fail and then code will be written and tested again. This process will keep repeating till the test is successful.
Test cases are typically automated in same language as the implementation language.
The steps involve –
· Writing unit test cases in collaboration between developers and testers
· Executing test cases
· Coding to address issues
· Executing test cases again and so on..
· Testers can do integration tests once Unit test is successful.
Behavior Driven Development (BDD)
This method started getting popular in the early 2000s and acceptance testing is the focus here. This is driven from the purpose of focussing on the expected behavior so that both technical and non-technical people are on the same ground. Typically implemented using many available tools in the market like Cucumber, Quantum, SpecFlow, JBehave etc.
Typically the test cases would be written in a language called Gherkin which follows a Given, When, Then format of specifying anything. Tests are written at scenario level and clearly maintained in feature files.
The end goal is to have a test case in natural language yet in a standard format. This can be understood and implemented by everyone working in the team and ensures end goal is met.
The steps involve -
· Identify the scenario for BDD
· Write the feature file in Given, When, Then format
· Run the feature file in appropriate language
· Check the test results of the run and fix the errors.
· Redo the process
Acceptance Test Driven Development (ATDD)
This also came into focus in the early 2000s. Acceptance testing is again the focus here as the name suggests but the purpose is clear capture of the requirements. This is also usually written in Gherkin and typically the tools used in BDD can be used here also. This brings customers to the testing table even before development has begun.
There are few situations where ATDD can do wonders. As the end goal is very clear to everyone, estimate are more accurate and collaboration improves in the team. It can help when technical debt is high in the project.
ATDD can be effective in reducing rework also due to clarity and save time. It reduces many problems Agile teams typically face.
The steps involve –
· Train the stakeholders on objectives and expectations
· Write the acceptance test cases
· Implement iterative learning
Domain Driven Development (DDD)
Understand the big picture and end goal. Once that is clear, decompose it into smaller deliveries and follow usual SDLC for the smaller pieces. This is the gist of domain driven development which came after all the other methods. This is not replacing any of the above methods but working in tandem with them to improve the process.
Summary
So do these methods exist separately? Is it a choice to pick one of them or all together?
It depends on the project but for a reasonably big one, all of them can be used together. In fact for best results, it may be good to combine some of them together and not just pick one.
- Start with the big picture by doing DDD
- Once decomposed into smaller pieces, go with BDD or ATDD or both as required
- Once further decomposed into unit level, developers need to work with TDD
There may be training period for the team to get accustomed to this but once there, the development process can improve and reduce issues as well.
Top comments (0)