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

Practical unit testing tips

on

  • 5,063 views

Practical unit testing tips from

Practical unit testing tips from

Statistics

Views

Total Views
5,063
Views on SlideShare
3,169
Embed Views
1,894

Actions

Likes
3
Downloads
32
Comments
0

5 Embeds 1,894

http://blog.typemock.com 1425
http://www.typemock.com 388
http://typemock.com 79
http://www.slideshare.net 1
http://localhost 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Practical unit testing tips Practical unit testing tips Presentation Transcript

    • Unit Testing
      Practical Tips
    • In the beginning
      First testing experience
    • 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
    • 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
    • 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
    • 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.
    • Why testing efforts fail
      When tests become frustrating
      Integration Tests != Unit Tests
      Slow
      Brittle – break unnecessarily
      Hard to Write due to highly coupled code.
    • Let’s test some code
    • 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.
    • Our “Unit Test”
      Database
      Web Service
      Session State
    • Step 1: Extract Class
      Single Responsibility Principle
      • Controller – Return correct view and viewModel
      • 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
    • Injecting Fakes
      ControllerTest
      Tests…
      Creates…
      Fake DB
      Repo
      Controller
      Uses…
      Fake DB
      Repo
    • Step 2: Fake object and Dependency Injection
    • Step 2: Fake object and dependency injection
    • Step 3: Abstract and Mock Session
      A Mock Example…
      • Specify behaviours
      • Specify expectations
      • Works for Interfaces, Abstracts and Virtuals
    • Step 3: Abstract and Mock Session
    • Step 3: Abstract and Mock Session
    • Tips
    • Tip: A handy private class
    • 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.
    • 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.
    • </end>