A presentation based on "The Art of Unit Testing" book by Roy Osherove to cover the key moments

1. Unit-Testing
Sergey Podolsky
sergey.podolsky@gmail.com

2. A “unit” is a method or function
A unit test is a piece of a code (usually a
method) that invokes another piece of code and
checks the correctness…
The Basics

3. We’ve all written unit tests (sort of)

4. A unit test should have the following
properties:
1. It should be automated and repeatable.
2. It should be easy to implement.
3. Once it’s written, it should remain for future
use.
4. Anyone should be able to run it.
5. It should run at the push of a button.
6. It should run quickly.

5. You’ve done integration
testing.
“What was I doing until now?”
you might ask.

6. integration
test

7. DEFINITION
• Integration testing means testing two or more
dependent software modules as a group.

8. Test-driven development

9. Testing Without Frameworks

10. Console Test

11. Running coded tests

12. …handmade Utilities

13. A first unit test

14. NUnit

15. log and notification project

16. Rules for naming tests

17. First Blood Test

18. Checking for expected exceptions

19. Setup and teardown

20. Ignoring tests

21. Setting test categories

22. Using stubs to break dependencies
• • Defining stubs
• • Refactoring code to use stubs
• • Overcoming encapsulation problems in code
• • Exploring best practices when using stubs

23. DEFINITION
• An external dependency is an object
in your system that your code under
test interacts with, and over which
you have no control. (Common
examples are filesystems, threads,
memory, time, and so on.)

24. DEFINITION
• A stub is a controllable replacement for an
existing dependency (or collaborator) in the
system. By using a stub, you can test your
code without dealing with the dependency
directly.

25. xUnit Test Patterns
by Gerard Meszaros
Fakes
Mocks Stubs

26. Identifying a filesystem dependency
in LogAn

27. The problem - an integration test
Direct Dependency test-inhibiting design
the code has some
dependency on an external
resource, which might break
the test even though the
code’s logic is perfectly valid

28. astronaut analogy
A space shuttle simulator
• Find the interface or API
• Replace the underlying implementation

29. Introducing a layer of indirection to
avoid a direct dependency on the
filesystem

30. Introducing a stub to break the
dependency

31. Refactoring our design to be more
testable
• DEFINITION Refactoring is the act of changing
the code’s design without breaking existing
functionality.
• DEFINITION Seams are places in your code
where you can plug in different functionality,
such as stub classes.

32. techniques for breaking dependencies
• Extract an interface to allow replacing
underlying implementation.
• Inject stub implementation into a class under
test.
• Receive an interface at the constructor level.
• Receive an interface as a property get or set.
• Get a stub just before a method call.

33. Extract an interface to allow
replacing underlying
implementation

34. Extracting a class that touches the
filesystem, and calling it

35. Extracting an interface from a known
class

36. Simple stub code that always
returns true

37. What’s next ???
Still have this:

38. Inject stub implementation into a
class under test
• Constructor
• Property
• a parameter to the method injection.
• a factory class
• a local factory method

39. constructor injection

40. Injecting our stub using constructor
injection

43. Problems with constructor injection:
more than one stub

44. Solution 1:
• parameter object
refactoring
create a special class that
contains all the values
needed to initialize a class

45. Solution 2:
inversion of control
(IoC) containers
• Spring.NET
• Castle Windsor
• Microsoft Unity
• Autofac
• Ninject
• StructureMap
http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx

46. Another Problem:
• 50 tests against your
constructor
• another dependency
you had not considered
• ????????
• change the call in 50
other tests !!!!!!!!!!!!

47. Advantages?
Parameters are non-optional for
user!

48. Receive an interface as a property
get or set

49. Injecting a stub by adding property
setters to the class under test

51. When a dependency of the
class under test is optional
dependency has a default
instance created

52. Use a factory class

53. Class under test

54. Test

55. Factory

56. Get more about factories in…

57. Using #if and #endif
with conditional compilation

58. • • Defining interaction testing
• • Understanding mock objects
• • Differentiating mocks and stubs
• • Exploring mock object best practices

59. DEFINITION
Interaction testing is testing how an object
sends input to or receives input from other
objects—how that object interacts with other
objects.

60. DEFINITION
• A mock object is a fake object in the system
that decides whether the unit test has
passed or failed. It does so by verifying
whether the object under test interacted
as expected with the fake object.
• There’s usually no more than one mock per
test.

61. Example – tree watering
• ❂ State-based testing
• ❂ Interaction testing

62. Differences between and
stubs can’t fail tests, and mocks can

63. MockWebService to record messages
that LogAnalyzer will send

64. Interface

65. Mock = Stub + ExtraCode

67. Stub + mock together
• Mock = Email service
• Stub = Web Service

68. E-mail to admin when web-service falls

71. Test

72. Stub - WebService

73. Mock - Email Service

74. RULE:
One mock per test
Other fakes = stubs

75. Stub chains
Solution technique:
A problem:

76. Isolation (mock object) frameworks
• • Understanding isolation frameworks
• • Defining fake objects
• • Using Rhino Mocks to create stubs and mocks
• • Surveying advanced use cases for mocks and
stubs
• • Exploring arrange-act-assert and record-and-
replay syntax
• • Avoiding common misuses of isolation
frameworks

77. DEFINITION
• An isolation framework is a set of
programmable APIs that make creating mock
and stub objects much easier.
• Isolation frameworks save the developer from
the need to write repetitive code to test or
simulate object interactions.

78. A problem:
Complicated interface

79. Handwritten
stubs

80. Dynamically creating a fake object
DEFINITION
A is any stub or mock that’s
created at runtime without needing to use a
handwritten implementation of an interface or
subclass.

81. • record-and-replay model
• arrange-act-assert model

82. Handwritten
mock

83. Dynamic Mock

84. will fail before verify()

85. strict mock can fail in two ways:
• expected methods aren’t called on it
• an unexpected method is called on it

86. • expected methods aren’t called on it
nonstrict mock can fail in one way:

87. nonstrict mock sample

88. Returning values from fake objects
Order does
not matter
Order
matters

89. You can also use LastCall to:
• LastCall.Throw(Exception)
• LastCall.Do( yourOwnDelegate )

90. Creating a stub in Rhino Mocks

91. Test doesn’t call an expected method

92. : auto implementing properties

93. : stub simulating exception

94. Combining dynamic stubs and mocks

95. Test logic:

96. Without frameworks:

97. With dynamic mocks & stubs

98. Parameter constraints for mocks and
stubs
LogAnalyzer sends "[Some GUID] Error message“
an example:
"33DFCC9D-D6C5-45ea-A520-A6018C88E490 Out of memory"

99. Using a string constraint in a test

100. Here’s the same test using the Text class:
LastCall.Constraints(Text.Contains("abc"));

101. The four types of constraints in Rhino Mocks

102. Testing for event-related activities
• Testing that an event has been subscribed to
• Triggering events from mocks and stubs

103. Testing that an event was registered properly

104. Triggering events from mocks and stubs

105. Another way of getting an EventRaiser
object is by using the recording

106. Arrange-act-assert syntax for isolation
Moq
Rhino
Mocks
Typemock
Isolator

107. Record-and-replay versus AAA-style
isolation

108. the same test using AAA syntax

109. the same test using Typemock Isolator
AAA syntax

110. Stubs in AAA-style isolation

111. Current isolation frameworks for .NET

112. Advantages of isolation frameworks:
❂ Easier parameter verification
❂ Easier verification of multiple method calls
❂ Easier fakes creation

113. automated build systems
• CruiseControl.NET (cruisecontrol.sourceforge.net)
• TeamCity (JetBrains.com)
• NAnt (nant.sourceforge.net)
• MSBuild
• (http://msdn.microsoft.com/en-us/library/wea2sca5(VS.80).aspx)
• FinalBuilder (www.FinalBuilder.com)
• Visual Build Pro (www.kinook.com)
• Visual Studio Team Foundation Server
(http://msdn.microsoft.com/en-us/teamsystem/default.aspx)

114. Separate unit and integration tests
(Safe Green Zone)
OR

115. Abstract test infrastructure class pattern
two test classes that reuse setup method

116. Template test class pattern
Similar to
contract
helps to test data-layer
CRUD (create, retrieve, update, and delete )
classes