Your SlideShare is downloading. ×
Practical unit testing tips
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Practical unit testing tips

4,617
views

Published on

Practical unit testing tips from

Practical unit testing tips from

Published in: Technology, Education

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,617
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
43
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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)
    (Dosens)
    Slow
    Unit Testing (automated)
    (Hundreds)
    Localize Failures
    Fast
    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-Driven-Design
    Test-First drives the Design – Low Coupling.
    Write only enough to make the test pass.
    YAGNI
  • 6. Automatic Test Generation?
    Only possible after the code has been written.
    You won’t get tests like…
    Test_that_user_registration_fails_on_invalid_ID()
    Doesn’t test Intent, can only test Methods.
  • 7. Why testing efforts fail
    When tests become frustrating
    Integration Tests != Unit Tests
    Slow
    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”
    Database
    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
    ControllerTest
    Tests…
    Creates…
    Fake DB
    Repo
    Controller
    Uses…
    Fake DB
    Repo
  • 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>