• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Unit testing
 

Unit testing

on

  • 452 views

My slides from the ERDDUG June 2011 meeting. The slides cover Unit Testing, what makes code hard to test and applying polymorphism to wire your application up differently in testing and production ...

My slides from the ERDDUG June 2011 meeting. The slides cover Unit Testing, what makes code hard to test and applying polymorphism to wire your application up differently in testing and production configurations.

Statistics

Views

Total Views
452
Views on SlideShare
409
Embed Views
43

Actions

Likes
0
Downloads
3
Comments
0

3 Embeds 43

http://www.mcdev.za.net 39
http://feeds.feedburner.com 3
url_unknown 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

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

    Unit testing Unit testing Presentation Transcript

    • Unit testing,mocking &tdd with .net
      ERDDUG – 11 June 2011
    • Types of Testing
      Scenario Testing
      You pretend to be a user.
      The app gets tested as a single unit. You’re testing by runningstatic void Main()
      Can’t test all edge cases.
      Functional Testing
      Sub-systems of the app get tested in isolation, e.g. by substituting databases with XML data sources.
      Ensures that groups of classes interact with each other correctly.
      When green – sure the subsystem works correctly.
      When red – easier to reproduce, but still need a debugger to find the exact problem.
    • Unit Testing
      Tests each individual class in isolation.
      Can simulate all edge cases and error conditions
      Fast – only instantiates the part of the app that’s actually needed for the test
      When green – know the class is OK in isolation, but haven’t tested interaction with others classes. (Functional test)
      When red – know we can reproduce the error easily.
    • What makes code hard to test?
      Real issues
      • Static calls
      • Singletons
      • Mixing new with logic
      • Work in constructor (static)
      • Global state
      • Deep inheritance
      • Conditionals
      • Mixing concerns
      Usual answers…
      • Make things private
      • Use sealed
      • Long methods
    • Unit Testing Classes
      Other Class
      Class Under Test
      Test Driver
      Other Class
      Other Class
      Object Lifetime and Calling
      Object Instantiated
      Object Passed In
      Global Object
    • Unit Testing Classes
      Other Class
      File
      System
      CPU Intensive
      Seam
      Other Class
      Other Class
      Class Under Test
      Test Driver
      Other Class
      Destructive operation
      Other Class
      Other Class
      Other Servers
      Object Lifetime and Calling
      Object Instantiated
      Object Passed In
      Global Object
    • Unit Testing Classes
      Seam (Polymorphism)
      Other Class
      Friendly
      Class Under Test
      Test Driver
      Other Class
      Friendly
      Other Class
      Object Lifetime and Calling
      Friendly
      Object Instantiated
      Object Passed In
      Global Object
    • Unit Testing Classes
      Seam
      Dependency
      Injection
      Friendly
      Class Under Test
      Test Driver
      Friendly
      Friendly
      Object Lifetime and Calling
      Object Instantiated
      Object Passed In
      Global Object