Acceptance Test Driven Development for Frontend
We have heard a lot about test-driven development (TDD). Now what is ATDD?
ATDD stands for Acceptance Test Driven Development, a software development methodology that defines acceptance criteria and creates automated tests to verify that those criteria are met.ATDD is a collaborative approach that involves a “Triad” - customers, developers, and testers working together to create a shared understanding of what needs to be developed and how it should be tested. ATDD is influenced by lean development principles, In which one principle is to reduce waste in a process. Creating acceptance tests upfront reduces waste by decreasing the loopbacks from testing back to coding. In addition, by involving the customer in the specification phase and creating automated acceptance tests that reflect the customer's requirements, the development team can be confident that they are building the right thing.
By creating automated acceptance tests that validate the software's functionality, the development team can arrest bugs and issues earlier in the development process when they are easier and cost-effective to fix.
If you are wondering where and how to start the ATDD process, Ken Pugh, in his book “Lean-Agile Acceptance Test-driven development: Better Software through collaboration”, recommends starting the ATDD by preparing a charter
A charter can include many sections, such as vision, mission, scope, deliverables, objectives, and principles
- vision – describes the end state of the result of the project—why the project should be done
- The mission – involves the path that will be taken to get to the vision
- The scope – documents the project’s boundaries, including the key events that the project addresses. The deliverables are the tangible outputs.
- The objectives – are measurable criteria for the success of the project that is visible by external observation.
- Principles – our statement of values that a team uses to inform decision-making. Other sections can include stakeholders (those affected by the project), project organization, plans for implementation, risks, and constraints.
Features -During the elicitation of high-level requirements, the triad also comes up with the high-level acceptance criteria for each of the high-level requirements.
The features need to be broken down into smaller pieces. Devising specific acceptance tests for smaller pieces is easier than for an entire feature.One or two features are broken down into stories—just enough to fill the team’s time until the next feature decomposition session. Personas are discussed as part of this exercise.
Scenarios are generated either through defining the Use cases or through story maps.
The final step of the process would be to implement the tests for all identified scenarios. These tests are refactored on a regular basis to keep up with the changing developmental needs.
Why is there a need for ATDD?
- ATDD encourages collaboration between the customer, development team, and testers, resulting in a shared understanding of the project requirements. This helps to ensure that the software being developed meets the customer’s needs and reduces the likelihood of misunderstandings and miscommunications.
- By defining acceptance criteria upfront and creating automated tests to verify them, ATDD helps to ensure that the software being developed meets the required quality standards. This can reduce the number of bugs and issues in the software, resulting in higher-quality products.
- With ATDD, tests are created before the code is written, providing immediate feedback to the development team on whether the code meets the requirements or not. This early feedback can help to catch issues early in the development process, reducing the overall development time and cost.
- By catching issues early in the development process, ATDD can help reduce the required rework. This can save time and reduce the cost of the project.
- ATDD promotes continuous improvement by encouraging regular acceptance criteria and test case reviews. This can help to identify areas for improvement and ensure that the software is continually meeting the customer’s needs.
Should everybody practice ATDD?
ATDD can be used in a variety of software development contexts, including agile, waterfall, and hybrid methodologies. However, ATDD is most commonly associated with agile methodologies, such as Scrum and Extreme Programming (XP), where it is often used as a part of the planning and estimation process.
A financial software development team used ATDD to develop a new Credit card payment system. They worked with creditors and banking professionals to define the acceptance criteria, which included the ability to enter applicant information, calculate outstanding credit card payments, approve or reject payments based on the available balance, restrict or arrest future purchases, etc. The team then created automated acceptance tests to verify that the system met these requirements.
Testing frameworks
Verification of the acceptance criteria are met through automated tests, these tests can be written by making use of any of the frameworks- Cucumber, FitNesse, JBehave, Gauge, etc.
Collaboration tools
Collaboration between the development team, the customer, and the testers is the aim of ATDD. Teams may need to employ software like JIRA, Trello, and Asana, among others, to facilitate smoother collaboration and track progress.
Continuous Integration (CI) tools
ATDD values continuous integration. To ensure that changes are tested and promptly incorporated into the main codebase, CI solutions like Jenkins, CircleCI, and Travis CI can be used to automate the build and testing process.
Version Control Systems
For the implementation of ATDD, version control systems like Git and SVN are essential. They make it possible for teams to efficiently coordinate and manage codebase changes.
Mocking and stubbing frameworks: ATDD mandates that acceptance tests be created before writing any code. Teams can establish acceptance tests early in the development process by using mocking and stubbing frameworks like Mockito and EasyMock to create fake objects and stubs to simulate dependencies.
While ATDD brings many advantages to the development team, there are also potential downsides that teams should be aware of:
- Creating acceptance tests can take a lot of time, and keeping them up to date can be difficult. In addition, as the codebase changes, teams must make sure the tests are current. This can be difficult, especially for complicated and big applications.
- Writing and maintaining the acceptance tests for ATDD involves a certain amount of technical competence. All team members might not be able to handle this, especially those who don’t have much experience with coding.
- Acceptance tests are not a magic bullet, but they can identify flaws early in the development process. However, even with acceptance tests, bugs can still get past, especially if they don’t cover every case.
- ATDD necessitates strong coordination between stakeholders, testers, and developers. The team may not be a good fit for ATDD if they lack effective communication and teamwork abilities.
Conclusion
In conclusion, ATDD can result in considerable gains in software quality, client satisfaction, and delivery time when implemented correctly. Yet, the failure of ATDD implementation can be attributed to the absence of clearly defined acceptance criteria, inefficient communication and collaboration, and lack of familiarity with the technique.
Sowmya Sridharamurthy
Sowmya Sridharamurthy is a seasoned product quality leader working as SDET Manager at Lytho. With 14+ years of experience handling products from inception to delivery, she has worked on diverse solutions- ERP, SAAS, Mobile Apps, and Web applications. She has a proven track record of successfully implementing result-driven test processes, non-disruptive migrations, and upgrades. Sowmya is driven to mentor development teams in building effective strategies and implementations to achieve ROI through test automation. Being an Accessibility advocate, she is keen on driving inclusive software development. Sowmya is an active community builder and runs an “APIans” meet-up group from Amsterdam.”
