Introduction to Test Driven Development
•
0 gostou•1,648 visualizações
This document provides an introduction to test driven development (TDD). It begins by clarifying that TDD is a design strategy, not just a testing strategy, and is intended for developers rather than testers. The core components of TDD - unit tests, functional tests, and integration tests - are explained. Benefits of TDD include less rework, regression testing due to refactoring, and faster development. Challenges include scaling TDD to larger projects and testing interfaces. The document concludes by emphasizing that code without tests is "broken by design."
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (7)
Destaque
Destaque (20)
Semelhante a Introduction to Test Driven Development
Semelhante a Introduction to Test Driven Development (20)
Mais de Siva Arunachalam
Mais de Siva Arunachalam (16)
Último
Último (20)
Introduction to Test Driven Development
- 1. Introduction to Test Driven Development Sivasubramaniam Arunachalam Mar 29, 2014 @sivaa_in http://barcampbangalore.org/bcb/bcb15/introduction-to-test-driven-development-tdd
- 2. It’s me!
- 5. Just Before We Get Started
- 6. How many of you are • Developers • Testers/Quality • Manual • Automated Manual/Automated Developers?
- 7. > 100K
- 8. > 5
- 10. No Opportunity
- 15. TDD is NOT a Testing Strategy
- 16. TDD is a Design Strategy
- 17. TDD is NOT for Testers
- 19. (1) – (2) – (3)
- 20. (1) – (2) – (3) Others Code
- 21. (1) – (2) – (3) Legacy Systems
- 22. (1) – (2) – (3) Change in Architecture
- 23. How to Start?
- 25. The Correct way
- 31. Refactoring? • Removing duplication • Make the logic simpler • Make the code easier to read
- 33. TDD Components • Unit Tests • Functional Tests • Integration Tests
- 34. Unit Tests
- 35. Unit Tests Best Practices • Focus one Class/Method • Keep it under 10 seconds • Execute 100 tests/second • Runs only on memory
- 37. Functional Tests
- 38. Are you ready now?
- 39. Everyone likes to have tests but Few people like writing them.
- 41. Only way to test Interfaces & Design
- 43. Helps to re-think what Needs to be Coded
- 44. Acts as a Low Level Spec
- 45. Less Rework
- 46. Regression due to refactoring This is the only way to find it
- 47. No More Dead Code Less code = Less bugs
- 48. Unit Tests might act as a Documentation
- 49. Less Debugging
- 51. Lets calculate the Cost 2 x $25 = $50 N x $M = $5K will become
- 54. By Products • Forces you to write small classes (focused on one thing.) • Helps create loosely coupled code • Measure implementation progress
- 56. Can I test Getters and Setters?
- 57. Can I test Third-Party Libraries?
- 58. (How) Can I test Private Methods?
- 59. (How) Can I test User Interfaces?
- 60. Be a Cool dude and exclude
- 61. Where to focus More and Less?
- 63. Mock Objects
- 64. Scaling
- 65. When do we FAIL?
- 66. Why businesses don’t like TDD?
- 67. How to start TDD for existing applications?
- 70. Is it really worth it?
- 73. Someone is using it? http://agilepainrelief.com/notesfromatooluser/2008/11/misconceptions-with-test-driven-development.html
- 74. Lets see some (test) code
- 75. Dis-advantages (You will lose) • Ability to say you are "done" before testing all your code. • Opportunity to learn through debugging. • Flexibility to ship code that you aren't sure of. • Freedom to tightly couple your modules. • Option to skip writing low level design documentation. • Stability that comes with code that everyone is afraid to change. • Capability to write hundreds or thousands of lines of code before running it.
- 76. TFD vs TDD
- 78. Code without tests is broken by design. - Jacob Kaplan-Moss
- 79. Debugging is twice as hard as writing the code in the first place. - Brian Kernighan
- 80. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian Kernighan