This document discusses Error Driven Development (EDD) as an alternative to traditional Test Driven Development (TDD). EDD emphasizes reproducing bugs through tests before fixing them. It addresses common reasons teams avoid TDD, such as not making mistakes or tests taking too long, by arguing bugs will still occur and fixing them without tests is not faster. EDD aims to have teams focus on bugs by learning to reproduce them in tests in order to fix issues and avoid regressions.
3. 1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10.Simplicity—the art of maximizing the amount of work not done—is essential
11.Best architectures, requirements, and designs emerge from self-organizing teams
12.Regularly, the team reflects on how to become more effective, and adjusts accordingly
The Manifesto for Agile Software Development
4. If you break something, no problem.
If you break it again, something bad is happening.
- Toni Navarro, the Battlefront guy
6. Why we are not writing software by TDD?
Feedback welcome!
Google Form with two questions
Why are we avoiding TDD?
How can we start using TDD?
7. Why we are not writing software by TDD?
- Usually, we don’t make mistakes
- We are not proficient with the testing framework
- TDD takes time: it slows the team
- The architecture is not test friendly
- Lazyness: “it’s just a small change”
- As it’s just a good practice, the team avoids it