Add TDD to your Toolbox: an introduction to TDD
•7 likes•1,366 views
Report
Share
Download to read offline
Introduction to TDD, test-driven development. Not included is a live coding demonstration of TDD in practice. Look at the link on the last slide for videos of other people doing TDD.
More Related Content
Viewers also liked
Viewers also liked(8)
Recently uploaded
![[2023] Putting the R! in R&D.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/2023puttingtherinrd-231122234738-294b2909-thumbnail.jpg?width=384&fit=bounds)
Recently uploaded(20)
![[2023] Putting the R! in R&D.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/2023puttingtherinrd-231122234738-294b2909-thumbnail.jpg?width=768&fit=bounds)
Add TDD to your Toolbox: an introduction to TDD
- 1. Add TDD to your toolbox an introduction for beginners Audrey Troutt @auditty
- 2. What is TDD? Test-Driven Development Audrey Troutt @auditty
- 3. Audrey Troutt @auditty Three conditions to achieve a flow state: 1. clear set of goals and progress 2. clear and immediate feedback 3. confidence in one's ability Csikszentmihalyi, M.; Abuhamdeh, S. & Nakamura, J. (2005), "Flow", in Elliot, A., Handbook of Competence and Motivation
- 4. “TDD is dead. Long live testing.” -David Heinemeier Hansson Read more: http://bit.ly/1foLebI Audrey Troutt @auditty
- 5. Materials needed: Source code Unit testing framework Understanding of requirements Audrey Troutt @auditty
- 6. Simple Case: There’s a bug Audrey Troutt @auditty
- 7. Use Case: From the Ground Up Audrey Troutt @auditty
- 8. “As the tests get more specific, the code gets more generic.” -Uncle Bob Martin Read more: http://bit.ly/1Bs2h70 Audrey Troutt @auditty
- 9. ● ({}–>nil) no code at all->code that employs nil ● (nil->constant) ● (constant->constant+) a simple constant to a more complex constant ● (constant->scalar) replacing a constant with a variable or an argument ● (statement->statements) adding more unconditional statements. ● (unconditional->if) splitting the execution path ● (scalar->array) ● (array->container) ● (statement->recursion) ● … and so on Read more: http://bit.ly/1Bs2h70 Audrey Troutt @auditty
- 10. Pros: ● More tests ● More testable code ● Discover missing requirements sooner ● Uncover novel designs ● Increased quality ● Refactor/add on with confidence ● Doesn’t generally take more time ● May start conversations Cons: ● First time setup of test framework takes extra time ● Not always practical (if requirements are not well defined) ● Makes changing object model harder ● May start conversations Audrey Troutt @auditty
- 11. “I credit TDD for teaching me how to test, and I still get huge benefits when I TDD. It’s not perfect, but no one technique is the key to magically producing better code.” -Justin Weiss Read more: http://bit.ly/1BVRR1y Audrey Troutt @auditty
- 12. Practice http://codekata.com/ Learn from others http://katas.softwarecraftsmanship.org/ Audrey Troutt @auditty
Editor's Notes
- April 2014 - this was dropped at RailsConf Test-first fundamentalism is ...an unrealistic, ineffective morality campaign for self-loathing and shaming. The gist of his argument is that we don’t need TDD anymore, it makes us sad, our object models become too complex and indirect, we can write isolated system tests that verify the business requirements. All respect to Mr Hansson, but I don’t agree with all of his points. He amplified a conversation that has been going on since TDD first came into wide use about whether it is useful at all. I leave that up to you, but I will say try it for yourself before you decide. Anyway, I’m not here to promote any particular testing religion. I see TDD as just another tool to use. I don’t use it all the time, in fact I use it pretty rarely these days. But, I have learned a lot about testing from having practiced TDD over the years and every now and then it is just the right tool for the job.
- So now that we’ve covered an overview and where TDD stands as a practice in use today, let’s talk about how to get started.
- I had a bug about a month ago: code to calculate the minutes from GMT for people who are currently experiencing X local time. I had TDD’d it, but I got it wrong. So, I wrote a failing test (in fact fixed a bad expectation in an existing test) and then went to the production code and got it to pass. Refactored, added another new test case, and refactored again. Two or three cycles and I was done. It was probably no more than 15 minutes. This is the most common case that I use TDD for these days. There are two benefits (besides just fixing the bug): 1) you are sure that you fixed the bug because you wrote a test that replicated the failure that you saw in production and 2) you have the test as an artifact, so that bug can never happen again!
- That’s a quick and simple use case, but where TDD really shines is when you are working from the ground up. New feature, new algorithm. What does it look like to use TDD to build from nothing?