Practical unit testing tips
Upcoming SlideShare
Loading in...5

Like this? Share it with your network

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 1,897 1,428 388 79 1
http://localhost 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


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