Unit Testing

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

Fill with products

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

questions?

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