First International Test Driven Development took place on July 10th.
In this series, I will include every talk together with my notes and further reading.
Hopefully, a lot of readers will watch and rewatch the talks, as they are worth several reviews.
Olena is a full stack developer at The Adecco Group from Berlin in Germany. She has previously worked in a service company based in Ukraine and took a part in the creation of various products from small startups, B2B applications, to enterprise platforms. Moreover, she is passionate about new technologies, clean code and best practices. In her free time, when she’s not spending it on hobbies, she likes to build demos around real-life use cases, share knowledge with others, and the opposite, learn about someone else's experience.
TL;DR: TDD Requires commitment con communication. People must agree with it to embrace it.
- TDD is complicated and time-consuming.
- One of her projects with TDD had very tight schedules and the team needed to rush.
- User stories were constantly changing.
- They had no idea how to write tests properly.
- The purpose of TDD was not well communicated.
- "Found a bug? Fix it. Write a test to prove it was fixed" methodology.
- They aimed at 100% code coverage
- Most of the test cases were useless, aimed at coverage, not at quality.
- They heavily used mocks.
- They didn't avoid critical defects.
- Useless cases with full mock combinations just to target 100% coverage
- This one was more BDD/Behavior-based.
- Just write the code needed to pass the test.
- BDD was easier to implement than TDD.
- After BDD, TDD is easier to carry on.
- TDD assists in better design.
- TDD breaks code into smaller pieces.
- TDD makes code easier to refactor.
- They used Cucumber
- Pre-release defect density on Microsoft and IBM decreased between 40% and 90% by using TDD.
- Most of the time we don't need a refactor stage.
- Even simple code needs tests because tests are also the specification.
Please follow TDD Conference on: