1 of 39

All about testing code

Introduction to software testing

2 of 39

Erlend Røsjø

Solutions Architect @ Sparebanken Vest��erlend.rosjo@nerdschool.no

Åse L Mattson

Developer @ Skatteetaten

Trym Helle

Consultant at Dfind Consulting�trym.helle@dfind.no

3 of 39

WIFI

Network name: “uib-guest”

Follow the instructions after connecting to the network

4 of 39

New to Nerdschool?

Nerdschool is a series of workshop exercises teaching tools and techniques commonly used in real software development
We aim for 10 - 12 workshops over a year, 5 - 6 per school semester

5 of 39

6 of 39

Agenda

What is software testing? Why do it?
Testing code
Test structure
Writing good tests
TDD
Dependencies

7 of 39

What is software testing?

8 of 39

What is software testing?

Manual testing

Testing code “by hand”

Automated testing

The computer tests your code

9 of 39

Why automate testing?

Late discovery of bugs = expensive
Automated testing can:

Discover problems early on
Quickly verify software correctness in a repeatable way

10 of 39

11 of 39

Automated testing

Enables code quality and reliability
Removes fear of change
Enables safe, rapid changes

12 of 39

The testing hierarchy

Unit tests

Integration

tests

System

tests

13 of 39

Testing code

14 of 39

Writing test code - JUnit

Test framework
Solves common problems
Widely used
.NET port: NUnit

15 of 39

Writing test code - Mockito

Mock framework
Avoid (“mock”) dependencies
Control flow during test runs

16 of 39

Test structure

17 of 39

Test structure

(Or: Arrange, Act, Assert)

18 of 39

A larger “Given”-block

19 of 39

Writing good tests

20 of 39

What does a good test look like?

Well named
DRY
Tests behavior, not implementation
Easy to diagnose on failure
Isolated
Stable - does not fail intermittently

21 of 39

Naming

Describes what we’re testing
Describes the conditions we’re testing for
Describes the expected result

public void getFullName_whenLastNameIsEmpty_returnsFirstName() {� ...�}

22 of 39

DRY - Don’t Repeat Yourself

23 of 39

Strategies for DRY

Use factory methods or builders to create test data
Move common setup/teardown to @Before, @After
Isolate test environment setup

But: Avoid Magic Numbers/Strings or data that’s “just there”

24 of 39

Testing behavior, not implementation

Test public API, not private
Don’t expose members just to test them
Test the result, not the internal details

25 of 39

Test-driven development

26 of 39

TDD - What

Tests first, then implementation, always
No code unless there is a test for it

27 of 39

TDD - Why

Ensures the test is testing what it claims
Enforces confidence/trust in tests
Enforces good architectural design early

28 of 39

TDD - Workflow

29 of 39

Exceptions, failures and errors

30 of 39

Exceptions in tests

What if an exception is the correct result?
JUnit lets you check for an exception using the @Test annotation:

@Test(expected = IllegalArgumentException.class)

public void someFancyTestThatThrowsAnException() {� ...�}

31 of 39

Failures vs. errors

Failures

Can happen when trying to check a behavior
Example: When an assertion fails

Errors

Can occur at any point in the test
Example: When the test throws an unexpected exception

Failures = Code under test is broken�Errors = test broken, code under test broken

32 of 39

Dependencies

33 of 39

Dependencies

A relationship between two components
Functionality of one component relies on another

public double calculateStudentLoanDebt() {� DebtRepository repository = new DebtRepository();� ...�}

34 of 39

35 of 39

Issues with dependencies

Test isolation
Coupled architecture
Example - three tier app

36 of 39

Dependency injection

A way of resolving test isolation and coupling issues
Example: Decoupling the three tier app

37 of 39

Assignments

38 of 39