5. The cost of bugs
Where does it hurt?
100%
The pain is here!
This is too late…
9
8
7
60%
6
5
40%
4
3
20%
2
1
0%
0
Requirements
Coding
Integration
% of Defects Introduced
Testing
Cost to Fix a Defect
Support
Thousand $s
% defects created
80%
10
6. When writing unit tests
Quick feedback
Am I writing the code right?
Am I’m writing the right thing?
Dependency & API analysis
Avoid stupid bugs
7. After writing a unit test
Immune to regression
Change your code without fear
Enable Rapid changes
In code documentation
8. What is a unit test?
Test specific functionality
Clear pass/fail criteria
Good unit test runs in isolation
9. This is a unit test
[TestMethod]
public void CheckPassword_ValidUser_ReturnTrue()
{
bool result = CheckPassword(“user”, “pass”);
Assert.IsTrue(result);
}
10. This is also a unit test
[Test]
public void CheckPassword_ValidUser_ReturnTrue()
{
bool result = CheckPassword(“user”, “pass”);
Assert.That(result, Is.True);
}
12. Arrange Act Assert
Divide the unit test into three parts:
[Test]
public void test() throws Exception
{
// Arrange
int first = 1;
int second = 2;
Calculator calc = new Calculator();
// Act
int result = calc.Add(first, Second);
// Assert
Assert.AreEquals(3, result);
}
13. Project structure
It is crucial to have a consistent naming convention:
For Project:
<project under test>Tests
or
<project under test>.UnitTests
<project under test>.IntegrationTests
For files (Test case):
<class under test>Tests
Example: CalculatorTests
Never have your test in the same project as your production code!
14. Test naming
Test names should be descriptive and explicit.
Test names should express a specific requirement
I like to use:
Method_Scenario_Expected
a.k.a
UnitOfWork_StateUnderTest_ExpectedBehavior
Public void Sum_NegativeNumberAs1stParam_ExceptionThrown()
Public void Sum_simpleValues_Calculated ()
Public void Parse_SingleToken_ReturnsEqualTokenValue ()
From: http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html
15. Test classification
Unit tests should be:
– Small
– Atomic
– Test a single functional unit
– Isolated!
Integration tests are used to test system wide functionality
19. Tools of the trade
Server
Build Server
Source Control
Build Script
Dev Machine
Unit Testing
Framework
Code
Coverage
Test Runner
Isolation
Framework
20. Continuous Integration Server
Build
What’s new?
Commit
There you go
Source Control
We automatically got
•Error reports & logs
•New version installer
•Help files
•More…
Build Agents
23. Development environment
• Make it easy to write and run tests
– Unit test framework
– Test Runner
– Isolation framework
• Know where you stand
– Code coverage
24. Unit test framework
Simplify the process of unit testing
Provide the following:
Control flow (attributes)
Signal success/failure (Assertions)
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
25. Assertions
Throw exception when condition is false.
Easy to find:
Assert.X
StringAssert.X
CollectionAssert.X
New Syntax (Nunit):
Assert.That(x, Is.Equal(y));
32. Unit tests != TDD
• The purpose of a unit test is to test a unit of code in isolation
• TDD is used to drive the design of an application.
• used to express what application code should do before the
application code is actually written.
36. Writing Some Code
We begin with a clean slate
Write
new
test
Run
tests
Refactor
Run All
tests
Write
code
37. Writing Some Code
An exercise in futility…
Write
new
test
Run
tests
Refactor
Run all
tests
Write
code
38. Writing Some Code
Now we get our hands dirty
Write
new
Test
Run
tests
Refactor
Run all
tests
Write
code
39. Writing Some Code
Make sure everything’s fine…
Write
new
Test
Run
tests
Refactor
Run all
tests
Write
code
40. Writing Some Code
… and make it perform/look better
Write
new
test
Run
tests
Refactor
Run all
tests
Write
code
41. Writing Some Code
Lets take her out for another spin…
Write
new
Test
Run
tests
Refactor
Run all
tests
Write
code
42. Want to learn more
Check out the bowling kata:
http://www.objectmentor.com/resources/articles/xpepisode.htm
More TDD problems:
https://sites.google.com/site/tddproblems/all-problems-1
43. OK, Who Broke the Build?
• Something went horribly wrong!
– And it’s easy to find who to blame
– But it’s easy to find out what happened
• Why is this important?
– The project heartbeat
– Healthy build == easy to release
44. Too Much Spare Time
The foosball table
The build bunny
The Shooting of The Zombies
Helping children with computer skills
•
•
•
•