[2/2] ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (ATDD. Software development through acceptance tests) (Category Engineering)

Continue. story I will tell you about the key principles of ATDD.

1. Collaborative specification of requirements. ATDD is based on the joint work of business customers, developers and testers to formulate test requirements. The cycle consists of four stages.:

• Discuss Discussion of user stories
• Distill - identification of acceptance criteria
• Develop development
• Demo - Prototype demonstration This approach ensures that all team members have the same understanding of goals. 2. Examples as the basis of communication. In ATDD, the team uses specific examples to describe the behavior of the system instead of abstract requirements. These examples serve as living documentation and should be written in a business language that is understandable to all participants in the process. 3. Automation as a literal interpretation. Acceptance tests should be automated so that they literally reflect the examples described. This means that automated tests become executable documentation that is always relevant and can serve as regression testing. 4. Testing before writing code. Similar to TDD, ATDD tests are created before productive code is written. This helps to focus on what the user really needs and avoid over-engineering. 5. Given-When-Then format. The Gherkin format with Given-When-Then designs is often used to describe scenarios. Given describes the initial conditions, When describes the user’s actions, then describes the expected results. This format makes tests readable for both technical and non-technical team members. 6. Focus on business value. Unlike unit tests, acceptance tests test functionality in terms of user and business value. They answer the question "does the system work as the customer expects" rather than "does a particular method work correctly." 7. Integration with the development process. ATDD does not replace other testing practices, but complements them. It combines perfectly with TDD at the modular test level, creating a multi-level quality assurance system. 8. Continuous feedback. Automated acceptance tests provide constant feedback on the state of the system. 9. Purity and support of tests. Acceptance tests should be written clean and maintained. They are long-term project assets and require the same attention to code quality as production code. Test refactoring is an integral part of the process. 10. Demonstration as validation. The final stage of the ATDD cycle is to demonstrate working functionality to stakeholders. This not only shows the result, but also allows feedback for further iterations. The demo serves as a validation point for what exactly was built.

As a result, the book is OK from the point of view of the base, but an update is needed in part. Using LLM to generate tests (more specifically inAcceptance Test Generation with Large Language Models: An Industrial Case Study")

• Use of the current stack (For example, Playwright or Cypress). Integration into CI/CD processes

P.S. The book is sent to the booksharing corner, which is located in our Moscow office. 7 floor (I hope she finds new readers.).

#QA #DevOps #Process #Software #Engineering #AI