Test driven development
Download as PPTX, PDF1 like356 views
This document discusses Test Driven Development (TDD). TDD helps create clean, simple code designs with low coupling between components. Writing tests first allows developing code with confidence as tests accumulate. It helps avoid technical debt by refactoring code as needed. TDD produces documentation in the form of executable tests and enables continuous integration and delivery. The TDD process follows the "Red-Green-Refactor" mantra of writing a failing test first, then code to pass the test, and refactoring code as needed. Tests should be written to be fast, independent, repeatable, self-validating, and timely. Tools and coding dojos can help practice and improve TDD skills.
Test driven development
- 2. 2
- 5. Agenda Why Test Driven Development Demo Test Driven Development Principle Hands On 5
- 6. Why Test Driven Development 6
- 7. Clean and Simple Design 7
- 8. TDD helps us to pay attention to the right issue at the right time so we can make our design cleaner . We can refine our design as we learn. Significantly increase the flexibility of your system, allowing you to keep it clean. Create a system design that has extremely low coupling. 8
- 9. Courage 9
- 10. TDD enables to gain confidence in code over time . As test accumulate , we gain confidence in the behavior of the system. Fear of making change disappear 10
- 12. Technical Debt Doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future. 12
- 13. Documentation 13
- 14. Create a suite of documents that fully describe the low level behavior of the system . Low level documentation that executes 14
- 16. Continuous Integration is a software development practice where members of a team integrate their work frequently each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. 16
- 18. What is continuous delivery ? reduce the cost , time , and risk of delivering incremental changes to users every requirement is a hypothesis 18
- 19. • Software always production ready – release tied to business needs , not IT constraints • Minimize the lead time from idea to live – Concept to cash 19
- 20. Test Pyramid 20
- 22. 22
- 23. Companies doing Continuous Delivery 23
- 24. Test Driven Development Principle 24
- 25. TDD Mantra Red – Write a little test that does not work , and perhaps does not even compile first. Green – Make the test work quickly , committing whatever sins necessary in the process. Refactor – Eliminate all of the duplication created in merely getting the test to work. 25
- 26. Keeping Test Clean Test code is just as important as production code. It is not second class citizen. What makes test clean Readability , Clarity , simplicity and density of expression 26
- 28. F.I.R.S.T Fast Tests should be fast. They should run quickly. When tests run slow, you won’t want to run them frequently. If you don’t run them frequently, you won’t find problems early enough to fix them easily. You won’t feel as free to clean up the code. Eventually the code will begin to rot. Independent Tests should not depend on each other. One test should not set up the conditions for the next test. You should be able to run each test independently and run the tests in any order you like. When tests depend on each other, then the first one to fail causes a cascade of downstream failures, making diagnosis difficult and hiding downstream defects. 28
- 29. Repeatable Tests should be repeatable in any environment. You should be able to run the tests in the production environment, in the QA environment, without a network. If your tests aren’t repeatable in any environment, then you’ll always have an excuse for why they fail. You’ll also find yourself unable to run the tests when the environment isn’t available. Self-Validating The tests should have a boolean output. Either they pass or fail. You should not have to read through a log file to tell whether the tests pass. If the tests aren’t self-validating, then failure can become subjective and running the tests can require a long manual evaluation. 29
- 30. Timely The tests need to be written in a timely fashion. Unit tests should be written just before the production code that makes them pass. If you write tests after the production code, then you may find the production code to be hard to test. You may decide that some production code is too hard to test. You may not design the production code to be testable. 30
- 31. Tools 31
- 32. • Visual Studio • Resharper • RhinoMock • Fitness • Specflow 32
- 33. Just do it! 33
- 34. Coding Dojo 34
- 35. What is coding dojo A Coding Dojo is a meeting where a bunch of coders get together, code, learn, and have fun The real point of going to a dojo is to improve your skills 35
- 37. Demo! 37
- 38. Convert Arabic number to Roman Number 38
- 39. Rules • Write test before writing any production code • Everyone must work in pair • One person should write one failing test and other should make that test pass by writing as minimum code as possible • Refcator code when necessary . You can only refactor code when all tests are in green • Write elegant code 39
- 40. 40
Editor's Notes
- #7: without a test suite we can not ensure that changes to one part of system did not break other part of system . So defect rate began to rise . As the number of unintended defect rose , we started to fear making changes . We stopped cleaning their production code because they feared the changes would do more harm than good .
- #9: When you follow the three laws and write your tests first, you are faced with a dilemma. Often you know exactly what code you want to write, but the three laws tell you to write a unit test that fails because that code doesn’t exist! This means you have to test the code that you are about to write.The problem with testing code is that you have to isolate that code. It is often difficult to test a function if that function calls other functions. To write that test you’ve got to figure out some way to decouple the function from all the others. In other words, the need to test first forces you to think about good design.If you don’t write your tests first, there is no force preventing you from coupling the functions together into an untestable mass. If you write your tests later, you may be able to test the inputs and the outputs of the total mass, but it will probably be quite difficult to test the individual functions.Therefore, following the three laws, and writing your tests first, creates a force that drives you to a better decoupled design. What professional would not employ tools that drove them toward better designs?“But I can write my tests later,” you say. No, you can’t. Not really. Oh, you can write some tests later. You can even approach high coverage later if you are careful to measure it. But the tests you write after the fact are defense. The tests you write first are offense. After-the-fact tests are written by someone who is already vested in the code and already knows how the problem was solved. There’s just no way those tests can be anywhere near as incisive as tests written first.
- #11: Why don’t you fix bad code when you see it? Your first reaction upon seeing a messy function is “This is a mess, it needs to be cleaned.” Your second reaction is “I’m not touching it!” Why? Because you know that if you touch it you risk breaking it; and if you break it, it becomes yours.But what if you could be sure that your cleaning did not break anything? What if you had the kind of certainty that I just mentioned? What if you could click a button and know within 90 seconds that your changes had broken nothing, and had only done good?This is one of the most powerful benefits of TDD. When you have a suite of tests that you trust, then you lose all fear of making changes. When you see bad code, you simply clean it on the spot. The code becomes clay that you can safely sculpt into simple and pleasing structures.When programmers lose the fear of cleaning, they clean! And clean code is easier to understand, easier to change, and easier to extend. Defects become even less likely because the code gets simpler. And the code base steadily improves instead of the normal rotting that our industry has become used to.What professional programmer would allow the rotting to continue?
- #15: Have you ever used a third-party framework? Often the third party will send you a nicely formatted manual written by tech writers. The typical manual employs 27 eight-by-ten color glossy photographs with circles and arrows and a paragraph on the back of each one explaining how to configure, deploy, manipulate, and otherwise use that framework. At the back, in the appendix, there’s often an ugly little section that contains all the code examples.Where’s the first place you go in that manual? If you are a programmer, you go to the code examples. You go to the code because you know the code will tell you the truth. The 27 eight-by-ten color glossy photographs with circles and arrows and a paragraph on the back might be pretty, but if you want to know how to use code you need to read code.Each of the unit tests you write when you follow the three laws is an example, written in code, describing how the system should be used. If you follow the three laws, then there will be a unit test that describes how to create every object in the system, every way that those objects can be created. There will be a unit test that describes how to call every function in the system every way that those functions can meaningfully be called. For anything you need to know how to do, there will be a unit test that describes it in detail.The unit tests are documents. They describe the lowest-level design of the system. They are unambiguous, accurate, written in a language that the audience understands, and are so formal that they execute. They are the best kind of low-level documentation that can exist. What professional would not provide such documentation?
- #27: If test is not readable , it’s difficult to understand for new developer . We write test so that it fail in the future when something goes wrong so readability is very important so that we can fix it easilyFollow “Arrange , Act , Assert”
- #36: Programmers generally love the plain activity of writing code, away from managers and deadlines and production bugs. When they’ve got over their shyness, most are delighted to show others how well they can actually write code, as well as to pick up tips and advice from them.