Scribd
Upload
373 views

Unit Testing

1. Unit testing involves testing individual units or components of an application in isolation from the rest of the code. This is done using a unit testing framework like JUnit. 2. There are different styles of unit testing like state-based testing and interaction-based testing. State-based testing focuses on the internal state of the unit under test, while interaction-based testing focuses more on the interactions and behavior of the unit. 3. When doing unit tests, test doubles like stubs, fakes, and mocks can be used to isolate the unit under test from its dependencies. This allows each unit to be tested independently without having to set up complex production

Uploaded by

Karthik Tantri
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
373 views

Unit Testing

1. Unit testing involves testing individual units or components of an application in isolation from the rest of the code. This is done using a unit testing framework like JUnit. 2. There are different styles of unit testing like state-based testing and interaction-based testing. State-based testing focuses on the internal state of the unit under test, while interaction-based testing focuses more on the interactions and behavior of the unit. 3. When doing unit tests, test doubles like stubs, fakes, and mocks can be used to isolate the unit under test from its dependencies. This allows each unit to be tested independently without having to set up complex production

Uploaded by

Karthik Tantri
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 17

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

You might also like