Unit Testing
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Unit Testing

  • 639 views
Uploaded on

Unit Testing presentation going through advantages, naming convention, testing frameworks, mocking frameworks...

Unit Testing presentation going through advantages, naming convention, testing frameworks, mocking frameworks...

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
639
On Slideshare
639
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
10
Comments
0
Likes
1

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 François Camus
  • 2. Advantages  Quick feedback loop  Run all tests to know if something is broken  Less need to run application to debug production code  Can debug from test method instead  Provides confidence  Refactoring  Releasing more often  Documents production code behaviour  Serves as production code safety net  Avoids Change And Pray syndrome (CPD)
  • 3. Test Project  Contains tests for a specific project  Naming convention  To avoid confusion  e.g. when browsing files  e.g. when having lots of tabs  Library namespace  e.g. OpenControl.Web.Mappers  Library Test Project namespace  e.g. OpenControl.Web.Mappers.Tests  Test Class name  e.g. ModelMapperTests  Test project to follow same structure as project being tested
  • 4. Unit Testing frameworks  Microsoft Test framework   NUnit  xUnit.net  http://xunit.codeplex.com/wikipage?title=Comparisons
  • 5. Test Execution Lifecycle  Initialization (before each test execution)  initialises dependencies and fields that are common to many tests  no setup here: each test does its own setup  Easier to maintain test code  Don’t want spaghetti test code all depending on a common setup method  Execution  Does local test setup  Calls method to test passing parameters and storing result if any  Asserts something on result or behaviour  Cleanup (after each test execution)  Dispose of initialized dependencies  Test Class initialisation and cleanup  Usually used by custom testing framework  e.g. Tester base class containing test helpers  Initialises before first test execution  Cleans up after last test execution
  • 6. Test method naming convention [Fact] public void Method_Condition_Result() {} 1. Method being tested 2. Condition to meet test result (optional) 3. Test result [Fact] public void GetData_DataExists_ReturnsData() {}
  • 7. Test method structure  AAA: Arrange/Act/Assert 1. Arrange: local test setup 2. Act: calls method to test 3. Assert: asserts result or behaviour  Common structure to all tests  Easier for other developers to maintain code  Helpful when doing Test Driven Development
  • 8. Interaction based Unit Testing  Asserting expectation on method  Couples to internal implementation  Less flexible to do refactoring  Leads to fragile tests  Easier when starting unit testing  Unavoidable  Need them when unable to only test result  e.g Testing that a void method was called  About 10% of tests  http://programmaticallyspeaking.com/?p=713
  • 9. State based Unit Testing  Tests method result rather than expectation  Easier to maintain  Only local test setup may need amendment  Preferred form of unit testing
  • 10. Testing internals  Add attribute to production code assembly info to make internals visible to specific library [assembly: InternalsVisibleTo("OpenControl.ClassLibrary.Tests")]  http://ayende.com/Wiki/Rhino+Mocks+- +Internal+Methods.ashx
  • 11. One assert per test  Atomic  Easier to understand  Easier to maintain  When refactoring production code, you get better feedback on what breaks
  • 12. Dependency Injection  Constructor parameter injection  Property injection
  • 13. Mocking  Mocking frameworks (all based on Castle Dynamic Proxy)  http://www.castleproject.org/projects/dynamicproxy/  Add attribute to production code assembly info: [assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]  NSubstitute  Shorter but awkward syntax  Less lambda so changing developers’ habits  Rhino Mocks  Too big (“Does the coffee !” Manu)  Confusion for new users on which syntax to use  Latest syntax is following state based unit testing approach  But old syntax remains  Large community  Moq  Smaller and simpler  Large community  http://code.google.com/p/moq/wiki/QuickStart
  • 14. Tools  Test Driven .Net (visual studio extension)  Works with xUnit.net (may need to run xunit installer to add support to Test Driven .Net)  ReSharper...  Jenkins  After build runs tests via plugin (xUnit plugin...)  Need to upgrade Jenkins to support .NET 4+
  • 15. Conclusion  Questions ?  TDD next time