Practical unit testing tips


Published on

Practical unit testing tips from

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Practical unit testing tips

  1. 1. Unit Testing<br />Practical Tips<br />
  2. 2. In the beginning<br />First testing experience<br />
  3. 3. Why Unit Testing?<br />Instead of starting by Testing Manually, you start by testing programmatically.<br />You test the code once…<br />… and then continuously afterwards.<br />Guards against others breaking your code.<br />Guards against regression errors.<br />Refactoring Ruthlessly<br />Peace of Mind<br />
  4. 4. Types of Testing – All Important<br />Functional Testing (manual)<br />Integration Testing (automated)<br />(Dosens)<br />Slow<br />Unit Testing (automated)<br />(Hundreds)<br />Localize Failures<br />Fast<br />Dynamic Language Debuggers<br />UI Layer<br />Person View<br />Person Controller<br />Person Model<br />Logic Layer<br />Security Manager<br />Data Layer<br />
  5. 5. Test-First of Test-After?<br />The difference is only When you write your tests?<br />Test-After is painful and boring.<br />Test-First makes unit testing easier. Unit Testing == Good. Win win situation.<br />Test-Driven-Design<br />Test-First drives the Design – Low Coupling.<br />Write only enough to make the test pass.<br />YAGNI<br />
  6. 6. Automatic Test Generation?<br />Only possible after the code has been written.<br />You won’t get tests like…<br />Test_that_user_registration_fails_on_invalid_ID()<br />Doesn’t test Intent, can only test Methods.<br />
  7. 7. Why testing efforts fail<br />When tests become frustrating<br />Integration Tests != Unit Tests<br />Slow<br />Brittle – break unnecessarily<br />Hard to Write due to highly coupled code.<br />
  8. 8. Let’s test some code<br />
  9. 9. What to test?<br />Single Responsibility Principle<br />Test the responsibility of the Controller Action.<br />ApplicationSuccess view should be returned if application succeeds.<br />ApplicationFailure view should be returned with a reason if application fails.<br />
  10. 10. Our “Unit Test”<br />Database<br />Web Service<br />Session State<br />
  11. 11. Step 1: Extract Class<br />Single Responsibility Principle<br /><ul><li>Controller – Return correct view and viewModel
  12. 12. UserCreditService – Contains user credit checking functions</li></li></ul><li>Step 2: Use fake Repository and fake UserCreditService<br />Fake objects replace the functionality of the of the real object with an alternate implementaiton, ie returning a canned list of values instead of hitting a database<br />Test Stub is an object that is used by a test to replace a real component to force the system down the path we want for the test. A stub may also record info about how it was called (ie. stub.wasMethodCalled())<br />Mocks fake implementation by returning hard coded values or values preloaded - they can also verify that the correct calls were made in the right order<br />
  13. 13. Injecting Fakes <br />ControllerTest<br />Tests…<br />Creates…<br />Fake DB<br />Repo<br />Controller<br />Uses…<br />Fake DB<br />Repo<br />
  14. 14. Step 2: Fake object and Dependency Injection<br />
  15. 15. Step 2: Fake object and dependency injection<br />
  16. 16. Step 3: Abstract and Mock Session<br />A Mock Example…<br /><ul><li>Specify behaviours
  17. 17. Specify expectations
  18. 18. Works for Interfaces, Abstracts and Virtuals</li></li></ul><li>Step 3: Abstract and Mock Session<br />
  19. 19. Step 3: Abstract and Mock Session<br />
  20. 20. Tips<br />
  21. 21. Tip: A handy private class<br />
  22. 22. Tip<br />Fine grained is better<br />100 tests that test 100 things is better<br />… than 10 tests that test a 100 things.<br />Execute the same action many times in different tests and verify different results in each call.<br />Makes errors easier to isolate.<br />
  23. 23. Tips<br />Break Dependencies – strive for low coupling<br />Use Dependency Injection<br />Avoid public Statics<br />Avoid Singletons<br />Use Interfaces to abstract calls to other classes<br />Use Mocks to mimic and test behaviour<br />Single Responsibility Principle – break things into smaller classes and test independently.<br />
  24. 24. </end><br />