A session I did at Rupin Academic Center. Part of modern software engineering course for bachelor degree in computer science.

1. Unit testing
Dror Helper
Senior consultant
Tuesday, Novemeber 19, 2013

2. “Traditional” development
Requirements
Design
Implementation
Verification
Maintenance

3. Integration surprises

4. Bugs are discovered too late

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);
}

11. Unit tests are written by developers

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

16. The test pyramid
Manual
testing
UI automation
Integration tests
Unit tests

17. The test pyramid
Manual
testing
UI automation
End to End flow tests
Scenario tests
Integration tests
Unit tests

18. Unit testing tools

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

21. Team Foundation Server (TFS)

22. TeamCity

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));

26. Attributes
Declare information about the test:
• TestClass/TestFixture
• TestMethod/Test
• ExpectedException
• Ignore
• And more

27. Test Runners
Visual Studio
 TestDrive.Net
 R# TestRunner
 CodeRush TestRunner


28. Code coverage

29. Test Driven Development
a software development process that relies on the
repetition of a very short development cycle

30. Test Driven Development
Red
Refactor
Green

31. The complete flow
Write
new Test
Run all
tests
Run Test
(fail)
Refactor
Write
code
Run test
(pass)

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.

33. Examples, demonstrations & fun
A DAY IN THE LIFE OF A TDD'ER

34. A Day in the Life of a TDD'er
• The tools we use
• Writing some code
• OK, who broke the Build?!
• Too much spare time…

35. The Tools We Use(d)
•
•
•
•
•
•
Unit testing – MSTest/NUnit
Build automation – FinalBuilder
Continuous Integration – TeamCity
Integrated tools – R#, TestDriven.NET
Isolation Framework – Isolator (surprise!)
Build Bunny!

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
•
•
•
•

45. The unit tester bookshelf

46. Presenter contact details
C: 972.50.7668543
e: drorh@codevalue.net
b: blog.drorhelper.com
w: www.codevalue.net