Lessons learnt from test driven development
Download as PPTX, PDF1 like679 views
The document discusses the challenges of maintaining product quality and the inefficiencies of relying solely on QA personnel, advocating for test-driven development (TDD) as a solution. TDD involves writing tests for new requirements before coding, encouraging frequent testing and refactoring to improve quality. The author emphasizes the importance of practical feedback and iterative development, drawing parallels to gym workouts, and highlights the necessity of adapting TDD to various situations.
Lessons learnt from test driven development
- 1. Lessons Learnt from Test-Driven Development By: Anand Powar
- 2. Once Upon A Time Our product has got quality issues Manager Developer We lack a good QA, lets hire one
- 3. 6 Months Later... Our development is slowing down Manager Developer There is just too much workload, we need to introduce a shadow resource
- 4. “One bad programmer can easily create two new jobs a year.” David Parnas
- 6. No Silver Bullet Good Cheap Fast
- 7. However A bit better A bit cheaper A bit faster Test-Driven Development
- 8. Test Driven Development Write new test New require- ment Run tests Write new code Run tests Refactor Run tests Make it Fail Make it Work Make it Better
- 9. It’s a lot like going to the gym
- 11. Use TDD where it's suitable, mix other styles
- 12. Only test things that can possibly break
- 13. Avoid bad design trade-offs
- 14. Yes, we still need QA
- 15. “Imperfect tests, run frequently, are much better than perfect tests that are never written at all” Martin Fowler
- 17. Acceptance criteria: It should be 4 inches tall Our hypothesis: 4 inches is the ideal size It should be able to walk At least 2 legs It should be able to jump If I drop it from a height of 2 inches, it should not break Build a toy dinosaur
- 18. 5 minutes
- 19. Children want a bigger dinosaur 6 inches tall Time to market We need to beat the competition Market Feedback
- 20. ASAP
- 21. Can your dinosaur still jump?
- 22. “If you don’t like unit testing your product, most likely your customers won’t like to test it either.” Anonymous
Editor's Notes
- #2: Hello everyone, My name is Anand and today I will be talking about 1. my experience while working with teams using TDD And later 2. We will follow this by playing fun game using lego bricks
- #3: Let me tell you a story, One day my manager had a meeting with the client where the client raised quality concerns
- #4: There was another complaint And again, I told him it’s not my fault And then we hired an intern
- #5: Thus proving who developed the concept of information hiding in modular programming (encapsulation)
- #6: So, you see, in order to achieve good quality and have a faster development we sacrificed on the 3rd angle: cheap In software development , we all have been looking for a technique which could help us produce good, fast and cheap s/w Do you know one ?
- #7: what i have realized is that there is no silver bullet
- #8: In Agile, there are a number of practices which can help make the s/w a bit better, a bit faster and a bit cheaper And TDD being one of them.
- #9: This is the TDD cycle, Here you write a unit test that doesn‘t work Then you Make the test work quickly (committing whatever sins necessary) And then you eliminate all of the duplication created in merely getting the test to work Loose coupling
- #10: You know it is good for you, all the arguments make sense, so you start working out. There's an initial rush, which is great, but after a few days you start to wonder if it is worth the trouble. You're taking an hour out of your day to change your clothes and run on a treadmill and you're not sure you're really gaining anything other than sore legs and arms. Then, after maybe one or two weeks, just as the soreness is going away, a Big Deadline begins approaching. You need to spend every waking hour trying to get "useful" work done, so you cut out extraneous stuff, like going to the gym. You fall out of the habit, and by the time Big Deadline is over, you're back to square one. If you manage to make it back to the gym at all, you feel just as sore as you were the first time you went. You do some reading, to see if you're doing something wrong. You begin feel a little bit of irrational spite toward all the fit, happy people extolling the virtues of exercise. You realize that you don't have a lot in common. They don't have to drive 15 minutes out of the way to go to the gym; there is one in their building. They don't have to argue with anybody about the benefits of exercise; it is just something everybody does and accepts as important. When a Big Deadline approaches, they aren't told that exercise is unnecessary any more than your boss would ask you to stop eating. http://stackoverflow.com/a/69263
- #11: Practice.
- #12: Remember the TDD is not a silver bullet. Depending upon the situation you should consider other styles: plain unit tests, BDD, ATDD and even manual testing http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html http://martinfowler.com/articles/is-tdd-dead/
- #13: We need not achieve 100% code coverage so my advise is to write tests for code that is prone to change. Ignore extensively 3rd party libraries and other reusable components As a developer you aren't paid to write tests, you just write enough to be confident
- #14: TDD is not just a testing technique but also a way to design your application architecture. When starting with TDD it's good to have a mentor who is knows about the common mistakes that developers make. Do pair programming with them.
- #15: Last but not the least
- #17: form groups of 5-6 people Identify observers
- #23: Did you unit test? Remind about the initial acceptance criteria. What did we learn?