Unit Testing

Unit testingVocabulary, styles, toys ____________________________

____________________________Vocabulary

[…]I'm a pretty lazy person and amprepared to work quite hard in order to avoid work. (Martin Fowler – The Value of Self Testing code)

• self validating (tests check their own results)

• fast

• easy (no long tutorials before being able to use)

• integrated

• extendable

JUnit framework

JUnit framework has become Widely Used

____________________________Vocabulary

“Unit tests are tests written with JUnit” (naive, simplistic, false)

Unit Tests

Integration, Functional, Acceptance Tests -> also written with JUnit If Unit tests cannot be defined via it’s Unit Testing Framework, what are they?

Unit Testing: - tests that perform a verification of a unit of code (article) - “a unit test has no dependencies” (article) - a method of testing that verifies individual units of source code are working properly (wikipedia)

Integration testing: - the part of software testing in which individual software modules are combined and tested together as a group.

____________________________VocabularyUnit Tests & not just tests

“One of the challenges of unit testing is to sufficiently decouple the multiple units of code that make up an application so that each unit can be tested individually.”

Unit Tests -> tend to become mini-integration tests!

Why should I Care?

Testing simple functionality (ex: new methods) in Integration Tests can lead to:

Fragile TestsUnrepeatable Tests…

Maintenance Nightmare

____________________________Styles

Non trivial tests: • Large number of dependencies• Awkward collaborations• Complex Objects How to isolate the units of code?

Using Test Doubles

Test Doubles : • Dummy - objects are passed around but never actually used. Usually they are just used to fill parameter lists.

• Fake - objects actually have working implementations, but usually take some shortcut which makes them not suitable for production

• Stubs - provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.

• Mocks - objects pre-programmed with expectations which form a specification of the calls

they are expected to receive.

____________________________Styles

What: Order : must fill itself from Warehouse

If Warehouse contains the product quantity requested by Order:- Order becomes filled, Warehouse quantity adjusted.

If Warehouse does not contain necessary quantity: -Order does not become filled. Warehouse unchanged.

Example

Order Warehouse

Fill with products

Products

____________________________StylesRegular test

____________________________Styles

How do we test a mail was sent?!

Stubs

With a Stub:

“Once,” said the Mock Turtle at last, with a deep sigh, “I was a real Turtle.”(Alice In Wonderland, Lewis Carroll)

____________________________StylesMocks

____________________________StylesMock test: jMock

____________________________StylesWe’re late!

____________________________Vocabulary

“The end justifies the means”

State-based testing

• Traditional (Classical) Unit Testing.

• Combines Stubs with Real Objects• Failing Tests – A collaborator may lead to multiple tests failed .• Unnecessary code – getters to expose state used only in tests. • Setup in a different place - a stub may be shared, it’s returned values not visible in the test• Sometimes stubs may be hard to implement by hand – how do we stub a HttpServletRequest? A java.io.File? What do we put in constructors? …

____________________________Vocabulary

“OOP should be Behavior Oriented Programming”

Interaction-based testing

• verifies the behavior of a unit.

• the only real class is the SUT (system under test)

• Failing Tests – A problem at a Unit fails only Unit’s test.

• Unnecessary code – don’t need state accessors. • Setup in setup - a stub returned values are visible in test.

• Stubs easy to be fabricated.

• In TDD -> leads to good design (Interface discovery, Tell Don’t Ask)….

____________________________VocabularyWhat should I use?

• Some code is very stateful, and is best tested with a state-based test. .

• Other code is more stateless and can be fully tested only with an interaction-based style

• Design phase – mocks may help

Maybe a better question:

• which style will be most effective for a particular piece of code?!

____________________________VocabularyGood Unit Tests

“Uncle Bob” suggests the F.I.R.S.T acronym in “Clean Code” to describe what well written (clean) unit tests should look like:

Fast - they should run quickly. This encourages you to run them often. (framework)

Independent - they should not depend on each other. It should be possible to run the tests in any order.

Repeatable - it should be possible to run them in any environment. They should be environment independent.

Self-Validating - they should either pass or fail. (framework)

Timely - they should be written in a timely manner i.e. just before the production code is written.

____________________________ToysMockito

____________________________questions?

http://martinfowler.com/articles/mocksArentStubs.html

http://code.google.com/p/mockito/

http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html

Martin Fowler: “Refactoring. Improving the design of existing code”

http://blogs.thoughtworks.com/

Robert “Uncle Bob” Martin: “Clean Code: A Handbook of Agile Software Craftsmanship”

http://mockobjects.com/http://benpryor.com/blog/2007/01/16/state-based-vs-interaction-based-unit-testing/