Unit testing
- 2. What is a Unit test? Unit testing is testing of units in your code base
- 3. “ The unit in question could be a Class or a Method...
- 4. What is NOT a unit test??? ◦ Developer Testing. Compiling and running the application to see if it does what you want it to do is not unit testing.
- 5. What is NOT a unit test??? ◦ Smoke/ Quality Testing. Running an automated test that chugs through a laundry list of procedures involving large sections of your code base is not a unit test. This is the way the QA department does testing.
- 6. What is NOT a unit test??? ◦ Things that involve databases, files, web services, device drivers or other things that are external to your code. These are called integration tests and they test a lot more than just your code.
- 7. “ The fact that something is automated does not make it a unit test
- 8. What is the purpose of Unit Testing? Testing is, at its core, experimentation. We’re just so used to the hypothesis that our code will work and that tests will confirm that to be the case. Or NOT!
- 9. What is the purpose of Unit Testing? Testing at the unit level is about running experiments on classes and methods and capturing those experiments and their results via code.
- 10. What is the purpose of Unit Testing? So unit testing is part of quality assurance, but it isn’t itself quality assurance, per se. Rather, it’s a way of documenting and locking in the behavior of the finest-grained units of your code – classes – in isolation.
- 11. What is the purpose of Unit Testing? By understanding exactly how all of the smallest units of your code behave, it is straightforward to assemble them predictably into larger and larger components and thus construct a well-designed system.
- 12. Some Basic Best Practices and Definitions
- 13. Basic Principles ◦ Unit tests are just methods that are decorated with annotations (Java) or attributes (C#) to indicate to the unit test runner that they are unit tests. Each method is generally a test. ◦ A unit test runner is simply a program that executes compiled test code and provides feedback on the results.
- 14. Basic Principles ◦ Tests will generally either pass or fail, but they might also time out or be inconclusive ◦ Tests will generally either pass or fail, but they might also time out or be inconclusive, depending on the tooling that you use.
- 15. Basic Principles ◦ Unit tests are simple and localized. They should not involve multi-threading, file I/ O, database connections, web services, etc. If you’re writing these things, you’re not writing unit tests but rather integration tests.
- 16. Basic Principles ◦ Unit tests are fast. Your entire unit test suite should execute in seconds or quicker. ◦ Unit tests run in isolation, and the order in which they’re run should not matter at all. If test one has to run before test two, you’re not writing unit tests.
- 17. Basic Principles ◦ Unit tests should not involve setting or depending on global application state such as public, static, stateful methods, singletons, etc.
- 19. Arrange What this means is that you start off the test by setting up the class instance in the state you want it (usually by instantiating it and then whatever else you want),
- 21. Assert Verify that what happened is what you expected to happen.
- 22. Lets write our first Unit Test
- 24. WOW ◦ Kind of a dense looking code there… ◦ How do we know if this works? ◦ Run the entire application to see if its blows up? ◦ But this is a pretty simple method in a pretty simple class. Doesn’t it seem like there ought to be a way to make sure it works?
- 25. But never fear ◦ Kind of a dense looking code there… ◦ How do we know if this works? ◦ Run the entire application to see if its blows up? ◦ But this is a pretty simple method in a pretty simple class. Doesn’t it seem like there ought to be a way to make sure it works?
- 26. But never fear
- 27. Why do we want to do this? ◦ Well, might be that you or someone else later starts playing around with the implementation of IsPrime(). ◦ Maybe you want to make it faster. ◦ Maybe you realize it doesn’t handle negative numbers properly and aim to correct it. ◦ ETC!
- 28. Donts
- 29. Donts ◦ Units test are granular! ◦ If something fails, you dont know what
- 30. Donts ◦ Units test are granular! ◦ If something fails, you dont know what!
- 31. “ “Unit tests don’t just magically spring up like mushrooms after a few days of rain. They’re more like roses – you have to plan for them from the start and carefully cultivate an environment in which they can thrive.”
- 32. How to get started! ◦ Test New Classes Only ◦ Test Existing Code by Extracting Little Classes ◦ Just do it!
- 33. Things that are hard to test ◦ Calls static methods. (is that they manipulate some kind of global state.) ◦ Invokes singletons . ◦ Dispatches background workers ◦ Accesses files, connects to databases, calls web services, etc. ◦ Has classes that require crazy amounts of instantiation.
- 34. Things that are hard to test ◦ For now just stay away from all of these...
- 36. Designs that are bad for testing ◦ Active Record This architecture tightly couples your database to your domain logic and your domain logic to the rules for navigating through domain objects. ◦ WinForms / Webforms / Code behind stuff
- 37. Monolithic Code ◦ Picture two methods. One is a 700-line juggernaut with more control flow statements than you can keep track of without a spreadsheet. The other is five lines long, consisting only of an initialize statement, a foreach, and a return statement. With which would you rather work?
- 38. Procedural Code
- 39. Procedural Code ◦ Stay away from this sort of Code ◦ Unit testing is about deconstructing things into smaller possible chunks
- 40. Procedural Code ◦ Stop thinking in when and start thinking in what ◦ If you were thinking about “what” first here, you would form a much different mental model of a person’s day. You’d say things to yourself like, “well, during the course of a person’s day, he probably wakes up, gets dressed, eats breakfast – well, actually eats one or more meals
- 41. Other Design Considerations for Your New Classes ◦ Avoid using fields to communicate between your methods by setting flags and tracking state. Favor having methods that can be executed at any time and in any order. ◦ Don’t instantiate things in your constructor. Favor passing them in.
- 42. Other Design Considerations for Your New Classes ◦ Similarly, don’t have a lot of code or do a lot of work in your constructor. This will make your class painful to setup for test. ◦ In your methods, accept parameters that are as decomposed as possible. For instance, don’t accept a Customer object if all you do with it is read its SSN property.
- 43. The earlier you start writing your unit tests, the better.
- 44. Other examples
- 45. Other examples
- 46. Still dont want to Unit Test? ◦ Improve code quality ◦ Document the code ◦ Exercise Code ◦ Promote good design ◦ Help break problems into manageable chunks ◦ Expose problems eairler ◦ Its cheaper to find problems ◦ Allow easier refactoring without hesitation
- 47. Still dont want to Unit Test? ◦ Improve code quality ◦ Document the code ◦ Exercise Code ◦ Promote good design ◦ Help break problems into manageable chunks ◦ Expose problems eairler ◦ Its cheaper to find problems ◦ Allow easier refactoring without hesitation
- 48. Still dont want to Unit Test? ◦ Its easier to write code with unit tests
- 49. Other considerations ◦ Name Your Tests Clearly and Be Wordy ◦ Dont name your test like: Test24, CustomerTest, ◦ Use: ◦ “Customer_IsValid_Returns_Fals e_When_Customer_SocialSecur ityNumber_Is_Empty”.
- 50. Other considerations ◦ Make your test suit fast. A good test suit runs in seconds ◦ Test code is nice code ◦ Have a single assert per case ◦ Dont share states between your test ◦ Encourage Others and Keep Them Invested
- 51. References ◦ Michael Feathers “The Deep Synergy Between Testability and Good Design.” Video ◦ Starting to unit test, not as hard as you think (Book) ◦ The art of unit test (Second Edition) Book!