Unit testing, principles

Unit Testing,Principles

@QuadraticBEJul. 2014

So it’s done...

I’m Renato Primavera from Quadratic

I write software that helps customers to manage and make use of their geographical data

@RenatoPrimavera renato.primavera@quadratic.be

www.quadratic.be

Unit testing is a method by which individual units of source code

are tested to determine if they are fit for use

In Java, it means mainly testing methods

Unit testing is different from Integration testing

in which individual software modules are combined and tested as a group in

their runtime environment

Unit testing is also different from Validation testing

which is the final process of checking that a software system meets

specifications and that it fulfills its intended purpose

So the goal of unit testing is to isolate each part of the program and show that the

individual parts are correct

A unit test provides a strict, written contract that the piece of code must satisfy

As a result,it affords several

benefits

Unit testing finds problems early in the development cycle

When the tests pass, that code is considered complete

Tests can be played frequently in an automated way, so any regression is highlighted ASAP

In test-driven development (TDD), unit tests are even created before the

code itself is written

Unit testing facilitates change

Unit testing allows the programmer to refactor code at a later date, and make

sure the module still works correctly

Unit testing provides a sort of living documentation of the system

Developers looking to learn what functionality is provided by a unit and how to use it can look at the unit tests to gain

a basic understanding of the unit's interface (API)

Unit testing improves

Software Quality

> Guidelines please...

First a few terminology

Assertiona statement that something should be true

Test Suitea collection of tests

Pass / Successtest that runs ok

Fail / Failuretest that does not pass

Fixtureall the things we need to have in place in order to run a test and expect a particular outcome. Some people call

this the test context

Test Double / Fake Object / Mock Objectssimulated objects that mimic the behavior of real

(complex) objects in controlled ways

Know what you're testing

A test written without a clear objective in mind is easy to spot. This type of test is long, hard to understand, and usually tests more

than one thing

(When a developer has a problem naming a test, that probably means the test lacks focus)

UT should be self-sufficient

A good unit test should be isolated. Avoid static variables usage and dependencies on external data (i.e. database, env settings)

A single test should not depend on running other tests before it, nor should it be affected by the order of

execution of other tests

UT should be deterministic

The worst test is the one that passes some of the time. A test should either pass all

the time or fail until fixed

Avoid writing tests with random input, that introduces uncertainty and prevent to reproduce the failure

Respect Naming Conventions

This is a good test name

public void throwsIllegalArgumentExceptionIfIconIsNull()

This is no so good

public void iconNullThrowsException()

This is terrible

public void throwsException3()

Duplicate code if needed

Readability is very important in unit testing, so it is acceptable to have

duplicate code

Having to change 4-5 similar tests is preferable to not understanding one non-duplicated test when it fails

Test results, not implementation

Successful unit testing requires writing tests that would only fail in case of an

actual error or requirement change

Testing the inner workings of how a feature was implemented may lead to test failure even if the result is the same

Use Isolation Frameworks

Writing unit tests can be hard when the class has complex dependencies.

Fake objects can help...

Instead of creating fake objects by hand, we can use mocking framework to create them with only a few API calls.

Arrggh! Anything else?

Adopt Unit Tests

Make them part of your development tasks

(as documentation ;) )

Avoid that !“I’ve no time…”

“It’s not my job…”“Tests ? But I never do bugs…”

“The real coder doesn’t test...”

Sourceshttp://en.wikipedia.org/wiki/Unit_testing

http://esj.com/articles/2012/09/24/better-unit-testing.aspx

Thanks