Unit Testing

Unit testing Vocabulary, styles, toys ____________________________

____________________________ Vocabulary […] 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 J U nit 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.

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

____________________________ Styles Regular 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) ____________________________ Styles Mocks

____________________________ Styles Mock test: jMock

____________________________ Styles We’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) … .

____________________________ 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 : F ast - they should run quickly. This encourages you to run them often. (framework) I ndependent - they should not depend on each other. It should be possible to run the tests in any order. R epeatable - it should be possible to run them in any environment. They should be environment independent. S elf-Validating - they should either pass or fail. (framework) T imely - they should be written in a timely manner i.e. just before the production code is written.

____________________________ Toys Mockito

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/

Unit Testing

More Related Content

What's hot (20)

Similar to Unit Testing (20)

Recently uploaded (20)

Unit Testing