____________________________

Unit testing

Vocabulary, styles, toys

Vocabulary ____________________________
JUnit framework
[…]I'm a pretty lazy person and am prepared 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 has become Widely Used

Vocabulary ____________________________
Unit Tests “Unit tests are tests written with JUnit” (naive, simplistic, false) 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.

Vocabulary ____________________________
Unit 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 Tests Unrepeatable Tests … Maintenance Nightmare 

Styles ____________________________
Using Test Doubles
Non trivial tests: • Large number of dependencies • Awkward collaborations • Complex Objects  How to isolate the units of code?

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 ____________________________
Example

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.

Order

Warehouse

Products

Fill with products

Styles ____________________________
Regular test

Styles ____________________________
Stubs
How do we test a mail was sent?!

With a Stub:

Styles ____________________________

Mocks

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

Styles ____________________________
Mock test: jMock

Styles ____________________________
We’re late!

Vocabulary ____________________________
State-based testing “The end justifies the means”
• 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 ____________________________
Interaction-based testing “OOP should be Behavior Oriented Programming”
• 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) ….

Vocabulary ____________________________
What 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?!

Vocabulary ____________________________
Good 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.

Toys ____________________________
Mockito

____________________________
Martin Fowler: “Refactoring. Improving the design of existing code” Robert “Uncle Bob” Martin: “Clean Code: A Handbook of Agile Software Craftsmanship” http://martinfowler.com/articles/mocksArentStubs.html http://mockobjects.com/ http://benpryor.com/blog/2007/01/16/state-based-vs-interaction-based-unit-testing/ http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html http://blogs.thoughtworks.com/ http://code.google.com/p/mockito/

questions?

Sign up to vote on this title
UsefulNot useful