The document discusses the advantages of unit testing, emphasizing quick feedback, confidence in refactoring, and serving as a safety net. It details conventions for naming test projects and methods, the lifecycle of test execution, and various testing frameworks like Microsoft Test Framework, NUnit, and xUnit. Additionally, it explores concepts such as dependency injection, mocking frameworks, and tools for test-driven development, culminating in a conclusion that invites questions on the subject.

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