2. Introduction
The main work is
performed in
implementation &
testing phases.
Unit tests save time &
improve design.
3. What is a unit test?
A unit test is a piece of a code (usually a method) that
invokes another piece of code and checks the correctness
of some assumptions afterward.
If the assumptions turn out to be wrong, the unit test has
failed. A unit is a method or function.
4. What a unit test should not do?
Unit tests are not about finding bugs, they’re all about code
verification.
Unit tests are not supposed to be built on top of existing
design for the sake of code coverage.
In fact, they should drive your system towards flexible &
testable design, thus providing an interface to verify the
correctness of the input/output of the unit.
5. Unit tests scope
The scope of Unit testing is narrow, it covers the
Unit or small piece of code under test.
Therefore while writing a unit test shorter codes
are used that target just a single class.
Unit tests should have no dependencies on
code outside the unit tested.
6. What exactly should be tested?
- Tests should be written for a specific CUT
- Tests should cover only the API of this CUT and are not
supposed to test the implementation details of a unit
- Test only units with some logic (e.g. methods and
functions not properties)
- It makes sense to test only those units over which you
have control
- Test CUTs against interfaces
7. Single Responsibility
Test behaviour, not methods:
- One method, multiple behaviours -> Multiple Tests
- One behaviour, multiple methods -> One Test
- A method calls private & protected methods
- A method calls properties
- One behaviour, one result -> One Assert
- Multiple asserts are okay as long as they check the
same behaviour
8. What makes a good unit test?
A good unit test should have the following properties:
- It should be automated and repeatable.
- It should be easy to implement.
- It should be relevant tomorrow.
- Anyone should be able to run it at the push of a button.
- It should run quickly.
- It should be consistent in its results.
- It should have full control of the unit under test.
9. What makes a good unit test?
A good unit test should have the following properties:
- It should be fully isolated from other tests.
- When it fails, it should be easy to detect what was
expected and determine how to pinpoint the problem.
- Fails when the logic against which it was tested changes
- Doesn’t make you want to comment them
- Doesn’t call other tests
- Are implemented quickly
- Covers multiple behaviours
10. How to verify that test is correct?
After implementing a test try changing the
behaviour of the unit, so it down not meet the
requirement anymore, and run it again. It should
fail.
Failing tests are as important as passing ones.
11. What is an integration test?
Integration testing is testing a unit of work
without having full control over all of it and using
one or more of its real dependencies, such as
time, network, database, threads, random
number generators, and so on.
12. Integration tests scope
The scope of Integration testing is wide, it
covers the whole application under test and it
requires much more effort to put together.
Integration testing is dependent on other
outside systems like databases, hardware
allocated for them etc.
13. Benefits of unit & integration tests
- Helps to improve and
build flexible design
- Verifies that code is
working as intended
- Helps to stick to
requirements
- Is a good source for
code documentation
- Unit tests are a form of
sample code
- Detect failing logic
upfront
- Measures the
completion of a class
- Pinpoints the problem
location
- Simplifies integration
15. Naming convention
UnitOfWork_StateUnderTest_ExpectedBehavior()
1. Unit of work - name of method you are testing
2. State under test - short name for the state/input used for current test
3. Expected behavior - short name for expected result of the test which
you’re going to check
16. Test Driven Development
Many people feel that the best time to write unit
tests for software is after the software has been
written, but a growing number prefer writing unit
tests before the production code is written. This
approach is called test-first or test-driven
development (TDD).
17. Red - Green -
Refactor
Write a failing test to prove code or
functionality is missing from the end
product.
Make the test pass by writing
production code that meets the
expectations of your test.
Refactor your code.
18. Additional resources
The Art of Unit Testing: with Examples in C#, Second Edition
by Roy Osherove
Writing Great Unit Tests: Best and Worst Practices:
http://blog.stevensanderson.com/2009/08/24/writing-great-
unit-tests-best-and-worst-practises/