Unit Test Lab - Why Write Unit Tests?

Unit Test Lab - Why Write Unit Tests?

• 1.
  UNITTEST LAB WHYWRITE UNITTESTS?
• 2.
  Reasons for nottesting Many programmers do not write tests. Many reasons are brought up. I don’t know how to write tests! Writing tests is too hard! Ain’t nobody got time fo’ dat! It’s not my job! Why would I test this? This code is so simple! Most of these are myths. Well, excuses, really…
• 3.
  Busting the mythsI don’t know how to write tests! Then learn. After all, tests are just code.You know how to write code, don’t you? Of course, tests do require thought. If you get lost, pair up! If you are not willing to learn, this might not be the job for you, anyway. There’s no new language to learn, and there’s no arcane magic involved. If you are not willing to think, this might not be the job for you, anyway. We’re all in this together! “I don’t know how to write tests!”
• 4.
  Busting the mythsWriting tests is too hard! Yes, it is hard. But so is writing good code. Having tests will make other things easier. Besides, we are probably in this line of work because we like solving problems. Tests positively impact all your other work. More on this later. “Writing tests is too hard!”
• 5.
  Busting the mythsAin’t nobody got time fo’ dat! You do. Being productive is all about In fact, what you don’t have time for is fixing the untested mess someone left you. Building new features Improving existing features Shipping a working product on time So why are we spending time Manually debugging our applications Introducing new bugs when fixing another Trying to understand other peoples’ code (because we know our own like the back of our hand, right?) “Ain’t nobody got time fo’ dat!”
• 6.
  Busting the myths Whywould I test this? This code is so simple! Maybe it is to you. Simple things tend to interact with other simple things. What you consider to be simple, may not be simple for other people to grasp. Interaction equals complexity. What may work under one set of conditions, may fail in another. When a test fails, it indicates a problem. This is a good thing! You are better off knowing. “Why would I test this?This code is so simple!”
• 7.
  Busting the mythsIt’s not my job! Then whose is it? You wrote the code. Expecting other people to mop up after you is rather unprofessional. Therefore, you know what it is meant to do. Testing your code unit is hard for other people to do, but easy for you. Don’t make other peoples’ lives harder. You will end up being the other person at some point. Expecting manual QA testing to catch most bugs is a myth in itself. Applications tend to grow. Manual testing tends to take orders of magnitude longer than automated testing. Do the math. “It’s not my job!”
• 8.
  NOWTHAT WE HAVE THATCLEARED UP WHY SHOULDWEWRITE UNITTESTS?
• 9.
  Reasons for writingunit tests 1. Tests Reduce Bugs in New Features 2. Tests Reduce Bugs in Existing Features 3. Tests AreYour Only Reliable Source Of Documentation 4. Tests Reduce the Cost of Change 5. Tests Improve Design 6. Tests Allow Refactoring 7. Tests Defend Against Other DevelopersWith Good Intentions 8. Testing ForcesYou to Slow Down andThink 9. Testing Makes Development Faster 10. Testing Reduces Fear! 10 Reasons Should Be Enough
• 10.
  Reasons for writingunit tests 1.Tests Reduce Bugs in New Features Note that they do not eliminate bugs, but they will force you to continuously execute your code against executable expectations. The more expectations are expressed, the higher your code coverage will be. Code coverage percentage is not the objective, though! Once a bug is found that did not cause a test to fail, make a test that fails under the circumstances that cause the bug to manifest itself.Then fix your code so that the test passes. Your code is now another step closer to being regression-proof.
• 11.
  Reasons for writingunit tests 2.Tests Reduce Bugs in Existing Features With well-tested code, introducing a new feature rarely breaks existing functionality. If a new feature does break existing functionality, one or more existing tests should fail immediately. You are now in a place where you can decide whether the existing functionality is at fault, or whether the new feature is implemented wrong. Importantly, you know this before deploying any code.
• 12.
  Reasons for writingunit tests 4.Tests Reduce the Cost of Change Tests make it easier to change software because you have confidence that changes will not break existing functionality. Poorly-tested software becomes increasingly expensive to change as time goes on. Risk increases dramatically as complexity increases simply because there is more code that can break, and there are more interactions that can cause the code to break.
• 13.
  Reasons for writingunit tests 5.Tests Improve Design Writing tests forces you to make your code testable. The things that make code hard to test, are generally also the things that make code hard to understand and hard to decouple. Singletons, static variables and global variables are things you will automatically tend to avoid. The end result is (usually) code that follows the S.O.L.I.D. principles of object-oriented design because S.O.L.I.D. deals with creating components that are loosely coupled, and highly cohesive.
• 14.
  Reasons for writingunit tests 6.Tests Allow Refactoring With tests, you are able to safely change code throughout the lifetime of an application. Tests reduce fear and uncertainty. The tests act as a safety net to ensure you don’t accidentally break something while you’re improving the design of the application. This encourages the changes to be made, which should lead to better, more understandable code.
• 15.
  Reasons for writingunit tests 7.Tests Defend Against Other DevelopersWith Good Intentions Textbook code is simple, but real-world code is hard. In real life, quirky business rules, operating system peculiarities or .Net framework bugs may require you to implement code that just looks funny. Having a test that requires those quirks to be expressed ensures that another programmer cannot come in and remove the quirky code, causing bugs to surface in certain circumstances. A comment would probably work, but comments do not have the added bonus of actually verifying that the code does what it is supposed to do. Besides, according to uncle Bob, all comments are lies. (Clean Code)
• 16.
  Reasons for writingunit tests 8.Testing ForcesYou to Slow Down andThink When adding a new feature or refactoring an existing solution, testing forces you to think about what the code is supposed to accomplish. By writing tests first, you think about how to use the publicAPI and what the ultimate outcome should be. By reasoning from the perspective of an API user, you tend to come up with a simple design that does exactly what it needs to do.
• 17.
  Reasons for writingunit tests 9.Testing Makes Development Faster On a class-by-class basis, testing slows you down. As time goes on, overall productivity increases because less time is spent worrying about breaking existing code, or even trying to work around existing code to avoid breaking it. Testing allows you to focus on the publicAPI, while ignoring implementation details. A suboptimal algorithm implementation can be replaced later when needed, knowing that the tests that exercise the publicAPI will protect the observable behavior.
• 18.
  Reasons for writingunit tests 10.Testing Reduces Fear! Having tests as a safety net allows you to add, change and deploy code with confidence.
• 19.
  ANY QUESTIONS?