Your SlideShare is downloading. ×
0
Unit Testing
Concepts, Tools and Best Practices
“I don’t have time to write tests
because I am too busy
debugging.”
Types of Software Testing
Unit Testing (do
the parts perform
correctly alone?)
Integration Testing
(do the parts
perform c...
The Concept of Unit Testing
 A unit test is code written by a developer that tests
as small a piece of functionality (the...
Unit Testing Tools
Production
Code
Unit Test
Code
Test
Runner
Unit Testing Tools
 Testing Frameworks
 NUnit
 Test Runner
 GUI
 Command line
 Automation
 CruiseControl.NET
Unit Test Hierarchy
Test Project
Test
Fixture
Test Test Test Test
Test
Fixture
Test Test Test Test
One per assembly
One pe...
Structure of A Unit Test
 Setup
 Prepare an input
 Call a method
 Check an output
 Tear down
Test Assertions
 Assertions are the ‘checks’ that you may perform to
determine if a test passes or fails.
 For instance:...
Unit Testing vs. Integration Testing
Busines
s Entity
Data
Layer
Data
Access
Layer
User
Interfac
e
Unit Testing tests one ...
Unit Testing with Mocks
Busines
s Entity
Data
Layer
Data
Access
Layer
Unit Testing tests one layer
A Mock allows a depende...
Executing Tests
Manually:
1. Compile Test project (to .dll or .exe)
2. Open in Test runner.
3. Select and execute tests.
A...
Sample Unit Test
Best Practices
Unit Test Best Practices
1. Consistent
2. Atomic
3. Single Responsibility
4. Self-descriptive
5. No conditional logic or
l...
Consistent
 Multiple runs of the test should consistently return
true or consistently return false, provided no
changes w...
Unit Test Best Practices
1. Consistent
2. Atomic
3. Single Responsibility
4. Self-descriptive
5. No conditional logic or
l...
Atomic
 Only two possible results: PASS or FAIL
 No partially successful tests.
 Isolation of tests:
 Different execut...
Unit Test Best Practices
1. Consistent
2. Atomic
3. Single Responsibility
4. Self-descriptive
5. No conditional logic or
l...
Single Responsibility
 One test should be responsible for one scenario
only.
 Test behavior, not methods:
 One method, ...
Single Responsibility
Sub TestMethod()
Assert.IsTrue(behavior1)
Assert.IsTrue(behavior2)
Assert.IsTrue(behavior3)
End Sub
...
Unit Test Best Practices
1. Consistent
2. Atomic
3. Single Responsibility
4. Self-descriptive
5. No conditional logic or
l...
Self Descriptive
 Unit test must be easy to read and understand
 Variable Names
 Method Names
 Class Names
 No condit...
Unit Test Best Practices
1. Consistent
2. Atomic
3. Single Responsibility
4. Self-descriptive
5. No conditional logic
or l...
No conditional logic or loops
 Test should have no uncertainty:
 All inputs should be known
 Method behavior should be ...
No conditional logic or loops
Sub TestBeforeOrAfter()
If before Then
Assert.IsTrue(behavior1)
ElseIf after Then
Assert.IsT...
Unit Test Best Practices
1. Consistent
2. Atomic
3. Single Responsibility
4. Self-descriptive
5. No conditional logic or
l...
No Exception Handling
 Indicate expected exception with attribute.
 Catch only the expected type of exception.
 Fail te...
No Exception Handling
<ExpectedException(“MyException”)> _
Sub TestException()
myMethod(parameter)
Assert.Fail(“MyExceptio...
Unit Test Best Practices
1. Consistent
2. Atomic
3. Single Responsibility
4. Self-descriptive
5. No conditional logic or
l...
Informative Assertion Messages
 By reading the assertion message, one should know
why the test failed and what to do.
 I...
Unit Test Best Practices
1. Consistent
2. Atomic
3. Single Responsibility
4. Self-descriptive
5. No conditional logic or
l...
No test logic in Production Code
 Separate Unit tests and Production code in separate
projects.
 Do not create Methods o...
Unit Test Best Practices
1. Consistent
2. Atomic
3. Single Responsibility
4. Self-descriptive
5. No conditional logic or
l...
Separation per Business Module
 Create separate test project for every layer or
assembly
 Decrease execution time of tes...
Unit Test Best Practices
1. Consistent
2. Atomic
3. Single Responsibility
4. Self-descriptive
5. No conditional logic or
l...
Separation per Type
 Align Test Fixtures with type definitions.
 Reminder: Unit tests are separate from integration
test...
 Images from Flickr
 Best practices from www.nickokiss.com
Unit Testing Concepts and Best Practices
Unit Testing Concepts and Best Practices
Unit Testing Concepts and Best Practices
Upcoming SlideShare
Loading in...5
×

Unit Testing Concepts and Best Practices

17,168

Published on

An overview of unit testing concepts and best practices. I gave this

Published in: Technology, Education

Transcript of "Unit Testing Concepts and Best Practices"

  1. 1. Unit Testing Concepts, Tools and Best Practices
  2. 2. “I don’t have time to write tests because I am too busy debugging.”
  3. 3. Types of Software Testing Unit Testing (do the parts perform correctly alone?) Integration Testing (do the parts perform correctly together?) User Acceptance Testing (does the system meet the end user’s expectations?)
  4. 4. The Concept of Unit Testing  A unit test is code written by a developer that tests as small a piece of functionality (the unit) as possible.  One function may have multiple unit tests according to the usage and outputs of the function.  Tests ensure  The code meets expectations and specifications: Does what it says it should do.  The code continues to meet expectations over time: Avoiding regression.
  5. 5. Unit Testing Tools Production Code Unit Test Code Test Runner
  6. 6. Unit Testing Tools  Testing Frameworks  NUnit  Test Runner  GUI  Command line  Automation  CruiseControl.NET
  7. 7. Unit Test Hierarchy Test Project Test Fixture Test Test Test Test Test Fixture Test Test Test Test One per assembly One per class One per unit (not necessarily per method)
  8. 8. Structure of A Unit Test  Setup  Prepare an input  Call a method  Check an output  Tear down
  9. 9. Test Assertions  Assertions are the ‘checks’ that you may perform to determine if a test passes or fails.  For instance:  Assert.IsTrue()  Assert.IsInstance()  Assert.AreEqual()  Generally speaking, you want ONE assertion per test.
  10. 10. Unit Testing vs. Integration Testing Busines s Entity Data Layer Data Access Layer User Interfac e Unit Testing tests one layer Integration Testing tests across layers.
  11. 11. Unit Testing with Mocks Busines s Entity Data Layer Data Access Layer Unit Testing tests one layer A Mock allows a dependency to be imitated so the Unit test can be isolated.
  12. 12. Executing Tests Manually: 1. Compile Test project (to .dll or .exe) 2. Open in Test runner. 3. Select and execute tests. Automatically: 1. Build server compiles and runs tests as part of nightly build operation. 2. Any test failures = entire build fails.
  13. 13. Sample Unit Test
  14. 14. Best Practices
  15. 15. Unit Test Best Practices 1. Consistent 2. Atomic 3. Single Responsibility 4. Self-descriptive 5. No conditional logic or loops 6. No exception handling 7. Informative Assertion messages 8. No test logic in production code 9. Separation per business module 10. Separation per type
  16. 16. Consistent  Multiple runs of the test should consistently return true or consistently return false, provided no changes were made on code Code that can cause problems: Dim currentDate as Date = Now() Dim value as Integer = New Random().Next
  17. 17. Unit Test Best Practices 1. Consistent 2. Atomic 3. Single Responsibility 4. Self-descriptive 5. No conditional logic or loops 6. No exception handling 7. Informative Assertion messages 8. No test logic in production code 9. Separation per business module 10. Separation per type
  18. 18. Atomic  Only two possible results: PASS or FAIL  No partially successful tests.  Isolation of tests:  Different execution order must yield same results.  Test B should not depend on outcome of Test A  Use Mocks instead.
  19. 19. Unit Test Best Practices 1. Consistent 2. Atomic 3. Single Responsibility 4. Self-descriptive 5. No conditional logic or loops 6. No exception handling 7. Informative Assertion messages 8. No test logic in production code 9. Separation per business module 10. Separation per type
  20. 20. Single Responsibility  One test should be responsible for one scenario only.  Test behavior, not methods:  One method, multiple behaviors  Multiple tests  One behavior, multiple methods  One test
  21. 21. Single Responsibility Sub TestMethod() Assert.IsTrue(behavior1) Assert.IsTrue(behavior2) Assert.IsTrue(behavior3) End Sub Sub TestMethodCheckBehavior1() Assert.IsTrue(behavior1) End Sub Sub TestMethodCheckBehavior2() Assert.IsTrue(behavior2) End Sub Sub TestMethodCheckBehavior3() Assert.IsTrue(behavior3) End Sub
  22. 22. Unit Test Best Practices 1. Consistent 2. Atomic 3. Single Responsibility 4. Self-descriptive 5. No conditional logic or loops 6. No exception handling 7. Informative Assertion messages 8. No test logic in production code 9. Separation per business module 10. Separation per type
  23. 23. Self Descriptive  Unit test must be easy to read and understand  Variable Names  Method Names  Class Names  No conditional logic  No loops  Name tests to represent PASS conditions:  Public Sub CanMakeReservation()  Public Sub TotalBillEqualsSumOfMenuItemPrices() Self descriptive
  24. 24. Unit Test Best Practices 1. Consistent 2. Atomic 3. Single Responsibility 4. Self-descriptive 5. No conditional logic or loops 6. No exception handling 7. Informative Assertion messages 8. No test logic in production code 9. Separation per business module 10. Separation per type
  25. 25. No conditional logic or loops  Test should have no uncertainty:  All inputs should be known  Method behavior should be predictable  Expected output should be strictly defined  Split in to two tests rather than using “If” or “Case”  Tests should not contain “While”, “Do While” or “For” loops.  If test logic has to be repeated, it probably means the test is too complicated.  Call method multiple times rather than looping inside of method.
  26. 26. No conditional logic or loops Sub TestBeforeOrAfter() If before Then Assert.IsTrue(behavior1) ElseIf after Then Assert.IsTrue(behavior2) Else Assert.IsTrue(behavior3) End If End Sub Sub TestBefore() Dim before as Boolean = true Assert.IsTrue(behavior1) End Sub Sub TestAfter() Dim after as Boolean = true Assert.IsTrue(behavior2) End Sub Sub TestNow() Dim before as Boolean = false Dim after as Boolean = false Assert.IsTrue(behavior3) End Sub
  27. 27. Unit Test Best Practices 1. Consistent 2. Atomic 3. Single Responsibility 4. Self-descriptive 5. No conditional logic or loops 6. No exception handling 7. Informative Assertion messages 8. No test logic in production code 9. Separation per business module 10. Separation per type
  28. 28. No Exception Handling  Indicate expected exception with attribute.  Catch only the expected type of exception.  Fail test if expected exception is not caught.  Let other exceptions go uncaught.
  29. 29. No Exception Handling <ExpectedException(“MyException”)> _ Sub TestException() myMethod(parameter) Assert.Fail(“MyException expected.”) End Sub
  30. 30. Unit Test Best Practices 1. Consistent 2. Atomic 3. Single Responsibility 4. Self-descriptive 5. No conditional logic or loops 6. No exception handling 7. Informative Assertion messages 8. No test logic in production code 9. Separation per business module 10. Separation per type
  31. 31. Informative Assertion Messages  By reading the assertion message, one should know why the test failed and what to do.  Include business logic information in the assertion message (such as input values, etc.)  Good assertion messages:  Improve documentation of the code,  Inform developers about the problem if the test fails.
  32. 32. Unit Test Best Practices 1. Consistent 2. Atomic 3. Single Responsibility 4. Self-descriptive 5. No conditional logic or loops 6. No exception handling 7. Informative Assertion messages 8. No test logic in production code 9. Separation per business module 10. Separation per type
  33. 33. No test logic in Production Code  Separate Unit tests and Production code in separate projects.  Do not create Methods or Properties used only by unit tests.  Use Dependency Injection or Mocks to isolate Production code.
  34. 34. Unit Test Best Practices 1. Consistent 2. Atomic 3. Single Responsibility 4. Self-descriptive 5. No conditional logic or loops 6. No exception handling 7. Informative Assertion messages 8. No test logic in production code 9. Separation per business module 10. Separation per type
  35. 35. Separation per Business Module  Create separate test project for every layer or assembly  Decrease execution time of test suites by splitting in to smaller suites  Suite 1 - All Factories  Suite II - All Controllers  Smaller Suites can be executed more frequently
  36. 36. Unit Test Best Practices 1. Consistent 2. Atomic 3. Single Responsibility 4. Self-descriptive 5. No conditional logic or loops 6. No exception handling 7. Informative Assertion messages 8. No test logic in production code 9. Separation per business module 10. Separation per type
  37. 37. Separation per Type  Align Test Fixtures with type definitions.  Reminder: Unit tests are separate from integration tests!  Different purpose  Different frequency  Different time of execution  Different action in case of failure
  38. 38.  Images from Flickr  Best practices from www.nickokiss.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×