A brief introduction to software unit testing.

1. Unit Testing
A (not so) short introduction
Company
LOGO
Alejandro Claro Mosqueda

2. What is all this stuff?!
AAA

3. QA key questions
Business Facing
Are we building the right product?
Are we building the product right?
Technology/Implementation Facing
Quality Assurance is more than look for bugs!

4. Accidental
Defects?
Essential
Defects?
Quality Assurance is more than look for bugs!
Critique Product
Supporting the team
QA key questions

5. Brian Marick’s test categorization

6. Test size classification

7. Ok! But what is a unit test?
A unit test is an automated piece of code that invokes the method being
tested and then checks some assumptions about the logical behavior of
that method.
It can be written easily and runs quickly.
It’s fully automated, trustworthy, readable, isolated, and maintainable.

8. What are they good for?
 Unit tests prove that your code actually works (at a function/method level).
 You get some kind of “low-level regression-test” suite.
 You can improve the design without breaking it.
 They demonstrate concrete progress.
 Unit tests are a form of sample code.
 It forces you to plan before you code.
 It reduces the cost of bugs.
 It's even better than code inspections.

9. What are they not for?
 It's not for testing correct inter-operation of multiple subsystems.
 It should be a stand-alone test which is not related to other
subsystems.
 Test against external resources (data base, LDAP, third party libraries, etc).
 Introducing dependencies on external resources or data turns unit tests
into integration tests.
 In many cases you can't write a unit test to reproduce bug appeared in
production.
 It's not regression testing.

10. Disadvantages
 Big time investment.
For the simple case you lose about 20% of the actual implementation, but for
complicated cases you lose much more.
 Design Impacts.
Sometimes the high-level design is not clear at the start and evolves as you go
along - this will force you to completely redo your test which will generate a big
time lose.

11. Best Practices!
 Make sure your tests test one thing and one thing only.
 Each unit test should be independent from the other.
 Keep consistent conventions (e.g. AAA). Readability is important for tests.
 Name your unit tests clearly and consistently.
 Separate you concerns. Extract layers to improve the design.
 Avoid unnecessary preconditions.
 Fake behavior with mocks or stubs to concentrate on test scenario.
 Check code coverage during testing.
 Don’t unit-test configuration settings.
 Tests should run automatically to provide continuous feedback. Keep the bar green to
keep the code clean!

12. Isolate!
State testing asserts properties on an object.
Interaction testing is testing how an object sends input to or receives input from other
objects — how that object interacts with other objects.
Stub is a controllable replacement for an existing dependency in the system. By using a
stub, you can test your code without dealing with the dependency directly.
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.

13. Naming by Unit Of Work
MethodUnderTest_Input_ExpectedOutput
MethodUnderTest_LogicalAction_ExpectedChangeInBehavior
MethodUnderTest_ActionOrInput_ExepectedCallToThirdParty
Addition_PositiveNumbers_ReturnsSum()
Addition_WhenCalled_ResetsTheNextSum()
Addition_NegativeNumbers_CallsLogger()

14. Arrange-Act-Assert (AAA) Pattern
Arrange: setup everything needed for the running the tested code. This includes any
initialization of dependencies, mocks and data needed for the test to run.
Act: Invoke the code under test.
Assert: Specify the pass criteria for the test, which fails it if not met.

15. Bad Practices and anti-patterns
 Static methods. Static methods are death to unit testability because they cannot
be mocked or stubbed.
 Relying on external resources.
 Unit test for GUI.
 Constrained test order.
 Hidden test call.
 Mutable shared-state.
 Multiple asserts.

16. Test fixture (Harness)
Test fixture refers to the fixed state used as a baseline for running tests. The
purpose of a test fixture is to ensure that there is a well known and fixed
environment in which tests are run so that results are repeatable.

17. Test fixture process

18. When do you write the test?
After/During coding
 Focus on code.
 Thinking about algorithm.
 More refactoring.
 Easier initially.

19. When do you write the test?
Before coding (TDD, BDD)
 Focus on requirements.
 Thinking about how code will be
consumed.
 Stop coding when reqs met.
 Harder initially.

20. Test driven development (TDD)
“TDD is a design process, not a testing process.”

21. Acceptance vs Unit testing
ATs and UTs are the same though, right?
 Both can be written before implementation.
 Both should be automated by containing assertions for validating expected
results.
 Both typically use fixture setup and teardown code to run before and after the
execution of the tests.
 Both can be implemented using a framework.

22. Black-box and White-box testing

23. Careful - They are NOT the same!
Acceptance test is owned and defined by the customer to verify that a
story is complete and correct.
 ATs must be defined in a language familiar to the customer:
 Generic enough to capture requirements
 Abstract enough to be maintainable
 Simple enough to be easily understood
 ATs should be defined and run using a tool accessible to the customer.
 ATs encourage the customer to consider the all aspects of user
experience.
 ATs test interaction of all layers in the system.
 ATs require external systems to be operating correctly.

24. Acceptance and Unit testing relation
setup
ATD
AT
impl
teardown
setup
ATD
AT
impl
Application Interface
Test
Implementation
Acceptance Test Client
Acceptance
Test Definition
Units
Implementation
Unit Test
Fixture
Setup
impl
UT
impl
impl
UT
UT
impl
teardown
UT
setup
ATD
impl
AT
impl
UT
impl
UT
teardown
Mock
Teardown

25. Acceptance Test Driven Development (ATDD)

26. Let’s talk!
Motivation is what gets you starting; practice is what
keeps you going