WHY UNIT TESTING?

BENEFITS OF UNIT TESTING

J. BARHEINE, J. BENSING, A. BUCHEN, M. WIRTH, P. ZHECHEV
2009-06-19

Contents
Introduction............................................................. 1
What is a unit test? ................................................. 1
Definition of an ideal unit test............................. 1
A pragmatic approach ........................................ 2
Code coverage................................................... 3
Benefits of unit tests ............................................... 3
Problems and limitations ........................................ 4
Enable unit testing .................................................. 5
Success stories ...................................................... 6
References ............................................................. 7
Appendix ................................................................ 8

Introduction
Even if software is developed since quite a
while software development organizations still
struggle to create software in reliable quality. The
numbers of bugs of a piece of code delivered from
a programmer to others is still high. Agile methods
have been put into practice more and more in the
last decade. Extreme programming (XP)
introduced in [Beck04] is a specific agile approach
with a strong emphasis on testing. It puts testing at
the foundation of development with every
programmer writing (unit) tests as they write their
production code.
In the second chapter we define an ideal unit
test as well as a corresponding pragmatic
approach. Since the question of code coverage
and its goals is asked repeatedly, we also give a
recommendation on this topic. The benefits of unit
tests, like shifting from defect detection to defect
prevention, are covered in the third chapter,
whereas the following fourth chapter depicts
problems and limitations coming along with unit
tests. We close with highlighting some topics to be
tackled to enable unit testing at SAP. Last but not
least you will find brief success stories on unit
testing outside SAP. The appendix contains
some more definitions of unit tests in literature.

What is a unit test?

floating around and it is difficult to get a single

overall definition. But one truth is that a test is not
automatically a unit test because it uses a xUnit
test framework. Unfortunately this is very often
assumed and misinterpreted.
An ideal unit test can be defined as follows and
is language independent:

A unit is an atomic piece of software which

cannot be decomposed further and that can be
separately tested in isolation (apart from any
other unit)

An introduction of dependencies on external

units/modules and/or data turns a unit test into
an integration tests ([Huettermann08] 98f.)

If one unit/module misbehaves in a chain of

inter-related modules, it is clear where to look for
the cause of the failure (without
mocking/isolation finding the point of failure is
tedious)

A unit test is executable anywhere at any time

(like a kind of a compile time or a build
verification test)

A unit test returns pass or fail against the code

under test

Code-centric: It focuses on code logic /

correctness of coding (developers expectation
and not customers expectation kind of
1
2
white /grey box testing)

A test has four distinct phases: fixture setup,

exercise software under test, result verification
and fixture teardown.

A very good definition which supports the

above definition is given by [Duvall07] (p. 132 and
141):
Unit tests verify the behaviour of small
elements in a software system, which are most
often a single class. [] Unit tests require the least
1 White box test checks correctness but not semantics of coding/code logic under test
( devs expectation) It is coded by developer.

Definition of an ideal unit test

Kent Beck introduced the concept of unit testing
in Smalltalk in the 70s. There are many definitions

2 Grey box test combines advantages of white box and black box tests. It is coded by
a developer BEFORE implementation of the specification.
3 A test fixture is all the things we need to have in place in order to run a test and
expect a particular outcome.

setup (by definition, none) [] A true unit test

should run to completion in a fraction of a second.
If a unit test takes longer [...] its either broken, or
instead of being a unit test, it is really a
component-level test. [] If unit testing takes
enough time that a developer can focus on
something else, its taking too long. [] therefore,
a unit test should run each time someone checks
in code (called the commit build). There is little
configuration cost, and the resource cost to run
them is negligible.
For example in ABAP a unit is a single method,
a function or a module. And ideally such a unit
should be tested in isolation, so it does not depend
on the execution of any other code snippet not
only if the depending code is not available yet.
Applying this principle enables early testing (and
does not start only after code is written) and
speeds up error detection since the piece of code
of potential errors is very limited and independent
of other code fragments. Here pops in the
architectural question: Is your code split in small
and independent pieces to support such an
4
approach? If necessary, use test doubles and
dependency injection to break dependencies.
Since the latter definition is quite strict in
respect of dependencies, it could increase the cost
and time to write unit tests tremendously to fulfil
this requirement. Therefore a balance between the
benefits of this strict definition and cost of
investment has to be found even if it softens the
definition. Simply consider ABAP unit tests or
Eclipse unit tests as an example. For both test
types the complete runtime is available and it
would not be wise to mock e.g. all dependencies
for Eclipse unit tests. But keep in mind that only
dependencies to rudimental functionality of the
Eclipse runtime should be used. But if you require
a heavyweight runtime environment probably most
benefits of a unit test will get lost and maintenance
of such environment could also be costly and timeconsuming.
An in-house example [SAP09] has shown that
5
with black box tests a high percentage (74%) of
code coverage has been achieved and with
additional white box tests the code coverage has
been increased by additional 4%. This let us

assume that unit tests do not have to be

necessarily white box tests. In test-driven
6
development (TDD) a developer can only write
grey box tests anyway since the key aspect of it is
to write tests before productive coding (more
precise: make production code work one test at a
time [Meszaro08], what is often mistaken as Testfirst). Pure white box tests are probably not that
stable when changing the logic of coding; therefore
it is recommended to start with grey box tests,
because they are expected to be stable when
changing internal coding.
To convince people to write unit tests it is very
key not only to provide a technical or a theoretical
definition, but also a practical approach and
characteristics or properties of a good unit test.
A pragmatic approach
The ideal goal to be achieved when writing unit
tests should always be the definition given above,
yet it is difficult to achieve for most of non-trivial
coding. Therefore a good unit test has at least the
following characteristics. [Osherove08] proposes
the following:

It is automated and repeatable

It is easy to implement

Once its written, it stays on for the future

Anyone can run it

It runs at the push of a button

It runs quickly

If a unit test fails the developer owning the code

fraction under test causing the failure, must be
able to fix it and must not depend on changes or
fixes in other code fragments which were not
tested directly via that broken unit test.
In addition to that this list can be enhanced by
the following topics (partly from [Staader05]):

Easy / inexpensive execution in an

economic/minimal test environment (e.g. during
build, ABAP unit tests)

Repeatable test fixture setup

6 Despite its name, TDD is not a testing technique, but rather a development and
design technique. Further reading in general: [Meszaro08b] and [Erdogamus05]; on
empirical evidence on TDD: [Siniaalto06] and [nagappan08]

4 See for further reading: http://xunitpatterns.com/Test%20Double.html

7 In xUnit, a test fixture is all the things we need to have in place in order to run a

5 Black box test checks fulfillment of specification and semantics of coding (

test and expect a particular outcome. Some people call this the test context. Some

customers expectation). It is coded by anyone not knowing coding/code logic under

variants of xUnit keep the concept of the test context separate from the Testcase Class

test.

that creates it; JUnit and its direct ports fall into this camp. Setting up the test fixture is

SAP AG 2009

Easy to localize point of failure

The tests should themselves be rather isolated.

A single test should not test different things.

It is easy to read/understand

Fast/rapid test-feedback (minimize time between

test runs, best case on each change or push of
the save button)

Bottom-up test it is the first test to be carried

out in development phase at the lowest technical
level.

Change of the logic of the code under test

breaks only a few unit tests

Test of pathological input parameters

One test must not interact with another test or

depend on each other

Code coverage
Usually unit testing is biased to looking at code
as it is implemented; therefore its thoroughness is
usually measured by code coverage (aka test
coverage). Code coverage measurement simply
determines those statements in a body of code
that have been executed through a test run and
those which have not; it is a method to assure the
quality of your set of tests (avoiding unit test
atrophy during development cycle) and to identify
gaps in your test suite, but not (!) the quality of
your product. This does not mean that a
component with high coverage is in a good shape
from quality perspective. It rather highlights parts
of your coding without tests.
Code coverage could be used for minimizing
and finding untested code.
Code coverage enables you to detect coding
what is probably not feature or requirement
relevant, since the effort for writing tests is for most
developers still too high to write tests for coding
nobody asks for. It also could be useful for identify
potential dead coding.
Contra-productive usage of the measurement
results is to define general KPI's of high coverage,
e.g. 80%. This leads to not implementing
meaningful tests if they do not lead to increased
coverage.
Usually the question is raised what coverage
goals to choose. There are no scientifically proven
papers out recommending any number to be set.
The goals for legacy coding and newly written
code might differ; it probably does not make sense

to increase coverage for code in maintenance

what is running at the customers side without
major errors. Nevertheless, there is a guideline for
mission critical software published under
[RTCA/DO-178B] by Radio Technical Commission
8
for Aeronautics (RTCA) which defines some
coverage goals for mission critical software.
[Cornett08b] recommends setting a reasonable
goal at 70-80%, for unit testing even 10-20%
higher. He also states that empirical studies have
shown that achieving code coverage above that
mentioned level is time consuming and less
productive
for
detecting
bugs.
Therefore
[Cornett08] suggests choosing intermediate
coverage goals following the code coverage
analysis strategy below:

Invoke at least one function in 90% of the source

files (or classes).

Invoke 90% of the functions.

Attain 90% condition/decision coverage in each

function.

Attain 100% condition/decision coverage.

Since some coverage tools do not support

condition (aka branch) coverage the weakest
metric to be used is at least statement coverage. A
good overview on metrics can be found in
[Cornett08].
Again, low coverage numbers simply indicate
inadequate testing, and high coverage does not
prove good quality.

Benefits of unit tests

An automated unit test suite implicates a
number of important, tangible advantages
compared to other test strategies whereas it has to
be emphasized that unit testing is only a part of an
overall test strategy putting testing to the
foundation of writing productive code; it is not a
standalone strategy. Unit tests executed within the
build is the heartbeat of any project. In best case a
failed unit test must lead to a failed build and even
prevent activation (e.g. in NWDI) of a submitted
change. So it is a kind of a safeguard to avoid that
other depending projects are affected by bug
infected coding; they can continue to work on the
last known working code.
The following list shows great benefits unit tests
bring along with especially when they are
created with TDD approach; the benefits are not all

the first phase of the Four-Phase Test. For meanings of the term test fixture in other
contexts, please see test fixture (disambiguation). [Meszaro08]

SAP AG 2009

8 http://www.rtca.org/

valid for a Test-last approach. Many topics are

taken from [Janzen06], [BurkeCoyner03] and
[Oracle04] but it is not entitled to be complete.
Defect Prevention Instead Of Defect
Removal. Having test at the foundation of writing
productive code, errors are discovered where and
when they are introduced. It also ensures that you
will not get regressions and speeds up more
expensive quality assurance cycles on even higher
level of testing like scenario testing.
Simplify Integration. By testing parts of the
coding first and afterwards testing many parts
together, eases the latter integration cycle.
Software
Architecture
/
Design
Improvement. If a method cannot be tested
easily, it can probably also not used easily. Unit
testing enforces the developer to write testable
code since it is very hard to test tightly coupled
code (so it enforces componentization). Going one
step further test (first) driven development
enforces the developer to focus on the interfaces
of a piece of software. It provokes the question
about what first and afterwards about how. In
other words, it forces you to slow down and think.
Reduce cost and risk of change. Tests
function as a kind of safety nets making it easy to
change the code with confidence not breaking
existing functionality. This is not only very
beneficial when it comes to support pack releases
and their maintenance, i.e. providing patches.
Besides this, putting quality assurance efforts from
correction phase to the bottom of development
phase reduces the number and the cost of errors
to be fixed in later stages.
Safeguard Shield Towards Depending
Components. Tests coupled with the build
infrastructure ensure that bugs do not escape to
depending components. Therefore it has an impact
on developer productivity.
Simplification Of Error Analysis. Since unit
tests only test a very specific piece of code it
speeds up finding the point of failure and the root
cause which avoids time consuming debugging
sessions.
Rapid Feedback. Since unit tests run quickly
(in seconds) and do not require a heavyweight
runtime environment, they can be executed very
often. So, on every change a developer applies to
a piece of code he can easily verify whether he
has broken anything.
Allowing Refactoring. Since test function as a
safety net, it allows to refactor coding at any time.

SAP AG 2009

Makes Development Faster. On a class-byclass basis, testing slows you down. It takes time
to think about and produce good tests. But as time
goes on, your overall velocity increases because
you are not constantly worrying about breaking
existing code as you add new features.
We have also found that with good tests, we
can ignore internal implementation details during
the first iteration. Provided that we get the public
API right, we can improve internal design and
algorithms later, again without fear of breaking
something. We have used this specifically for
things like sorting algorithms. In the first iteration,
we do something quick and dirty, like a bubble
sort. We can always come back later and replace it
with
a
better
algorithm,
if
necessary.
([BurkeCoyner03]). Besides that, time used for
debugging will be reduced.
Enables low level testing. Unit tests,
especially white box tests, allow you to test internal
conditions that are not easily reached by external
inputs, whether all error cases are correctly
detected and if all special cases work correctly.
Ease higher level testing. Even higher level
tests like integration or scenario tests benefit from
the safety net unit tests provide since each unit
works in separation. Therefore integration tests
can focus on the cooperation of individual parts.
Easy to maintain, easy to run, but hard to
develop for non-trivial code. In comparison to
higher level tests like UI based QTP tests, unit
tests have a very low effort for maintenance
whereas currently it is difficult to keep a UI based
QTP test stable. Unit test also do not require
properly configured, heavyweight systems; instead
they simply can be executed fast and reliable in
very simple test landscapes.

Problems and limitations

Unit testing seems much more popular in
theory than in practice. Even if unit testing
promises to allow continuously test small pieces of
code without the hassles of working on a complex
system the main problem for this has to be solved.
To create such an initial environment, allowing you
to run tests in isolation and ensuring at the same
time that the behaviour of the code under test
behaves similar as it would be as part of the
complete system, can be difficult. But having those
conditions is essential. Developers trying to
accomplish that could get frustrated by the amount
of work they have to initially invest. Therefore
developers usually have reservations towards

testing in general and unit testing in particular.

Many times a hindrance could be how to write
tests if the code under tests requires a specific
runtime container (e.g. JEE container). In SAP we
also have gaps enabling unit testing for several
used technologies like any in-container modules
(JEE, web, portal, etc.), WebDynpro, Galaxy, etc.
Each of the mentioned technology requires a
specific environment. In addition to that, a SAP
Java developer has to overcome the problem of
only being allowed to reference so called facades
which only contain APIs and not the
implementation. But the implementation is required
at test execution time. This is a hindrance to write
runtime independent, standalone unit tests. In
other words lack of knowledge and good unit test
cookbooks for each used technology of how to
write good unit tests are missing.
Currently, in the SAP Java stack the biggest
insurmountable obstacle when it comes to unit
testing is the monolithic design. There exists a big
chunk of legacy without unit tests and it is difficult
to implement unit tests for this coding since it
simply not really designed for unit testing.
Fact is also, that the initial effort for writing unit
tests is not even close to zero. Usually
development cycles are overloaded and testing
seems to be additional workload with low priority.
Therefore, not budgeting an adequate amount of
time for test creation and test enhancement, in
parallel to implementing productive coding, and
missing management backing (what is shortsighted considering the advantages) will lead to
failure of adopting the unit test approach in SAP.
[Osherove08] says also that Many people
confuse the act of simply testing their software with
the concept of a unit test. To start off, ask yourself
the following questions about the tests youve
written up to now:

If any of those questions are answered with

no, it is probably not a unit test. Therefore
educating people on unit test is essential.
However, unit tests are not a panacea solving
all problems. Errors related to functions performed
across several units (e.g. during integration or
scenario tests) cannot be covered; Non functional
tests
like
performance,
stress,
usability,
acceptance et cetera are also not covered.

Enable unit testing

Writing cost effective unit tests is not trivial. It is
just like writing any other type of software: it takes
time, effort and skill. How much time has to be
evaluated during several sprints. The case study of
[SAP09] shows that almost 33% of the time was
used for writing unit tests. Several other, not
academically proven numbers on the internet state
also that it takes approximately 30% of the time.
Depending on the approach, either writing tests
separately or applying TDD, the additional required
time diversifies. In TDD it is probably less.
To get started with unit testing in SAP the
following topics have to be considered:

Start writing Unit Tests as early as possible.

Where suitable apply the TDD approach - but be
aware that this is a paradigm shift in
development for most organisation units (like the
shift from procedural to object-oriented
programming).

Provide a centre of expertise supporting

development teams / scrum teams at least in the
initial phase on unit testing and TDD

Train a local expert and set up a local community

on unit testing

Can I run and get results of a unit test I wrote

two weeks/months/years ago?

Educate developers (trainings, train the trainer,

hands-on sessions)

Can any member of my team run and get the

results from unit tests I wrote two months ago?

Provide guideline and education how to write

testable code incl. training on design pattern

Evaluate for all used SAP technologies/runtime

containers (not only for components on the
bottom of the stack) how unit tests can be
implemented. Provide best practice for those
runtime containers how to implement unit tests
and examples including usage of test double
9
10
frameworks (like MockObjects , EasyMock ,
11
JMock , TestDouble Framework [ABAP]),

Can it take me no more than a few minutes to

run all the unit tests Ive written so far?

Can I run all the unit tests Ive written at the push
of a button?

Can I write a basic unit test in no more than a

few minutes?

Can I fix a failed test, by simply directly changing

the targeted code by the test (no depending
code)?

9 http://sourceforge.net/projects/mockobjects
10 http://easymock.org/
11 http://www.jmock.org/

SAP AG 2009

injection frameworks (like PicoContainer

13
14
Google-Guice ) or tools like DBUnit ,
15
EJB3Unit etc

12

or

Since SAP uses technologies/runtime containers

which cannot be unit tested with common unit
test frameworks, those areas providing that
technology have to provide either a very
lightweight runtime environment or a
corresponding unit test framework supporting
tests matching the above mentioned definition
and characteristics. Providing that for legacy
coding could be very difficult. But for new
runtime containers that aspect has to be
considered very seriously.

If a technology/runtime containers cannot be unit

tested, stop development of such a
technology/runtime container

The problem of generated coding has to be

solved or alternatively find a way to test the
generator and (!) the models used for input

Enable production infrastructure (e.g. NWDI) to

run unit tests during build and attached tasks
(e.g. rejecting submit or activation of changes).
[Duvall07] (p. 27) defines build as A set of
activities performed to generate, test, inspect
and deploy software.

If defining KPIs for any unit testing activity,

strongly distinguish between legacy coding and
new coding. Monolithic designed legacy coding
at SAP is usually not made for unit testing.
Last but not least the unit testing approach
must be backed by management.

Success stories
Finally, this section gives you an overview of
known success stories in respect of unit testing
also combined with the TDD approach.
IBM / North Carolina State University. A
development team in IBM transitioned from an
adhoc to a TDD unit testing practice []. Through
the introduction of this practice a relatively
inexperienced team realized about 40% reduction
16
in FVT detected defect density of new/changed
code []. Additionally, the suite of automated unit
test cases created via TDD became a reusable
and extendable asset that will continue to improve
12 http://www.picocontainer.org/
13 http://code.google.com/p/google-guice/
14 http://www.dbunit.org/
15 http://ejb3unit.sourceforge.net/
16 Note: functional verification test

SAP AG 2009

quality over the lifetime of the software system.

[]. Through the TDD practice, a significant suite
of regression test cases are created and the code
is developed in a testable manner. [William03], p.
8
Microsoft / IBM. Case studies were conducted
with three development teams at Microsoft and
one at IBM that have adopted TDD. The results of
the case studies indicate that the pre-release
defect density of the four products decreased
between 40% and 90% relative to similar projects
that did not use the TDD practice. Subjectively, the
teams experienced a 1535% increase in initial
development time after adopting TDD. [] recent
contact with the IBM team indicated that in one of
the subsequent releases (more than five releases
since the case study) some members of the team
(grown 50% since the first release) have taken
some shortcuts by not running the unit tests, and
consequently the defect density increased
temporally compared to previous releases.
[Nagappan08], p. 289, 299

References
[Beck04]

Kent Beck and Cynthia Andres.

Extreme Programming Explained:
nd
Embrace Change, 2 Edition.
Addison-Wesley Professional,
2004
[BurkeCoyner03] Eric M. Burke, Brian M. Coyner.
Java Extreme Programming
Cookbook, OReilly, 2003, excerpt
on
http://www.onjava.com/pub/a/onjav
a/2003/04/02/javaxpckbk.html,
2009-04-16
Steve Cornett. Code Coverage
[Cornett08]
Analysis, Bullseye Testing
Technology, 1996-2008,
http://www.bullseye.com/coverage.
html#intermediate, 2009-04-15
Steve Cornett. Minimum
[Cornett08b]
Acceptable Code Coverage,,
Bullseye Testing Technology,
1996-2008,
http://www.bullseye.com/minimum.
html, 2009-04-15
[Duvall07]
Paul M. Duvall with Steve Matyas
and Andrew Glover. Continuous
Integration: improving software
quality and reducing risk, AddisonWesley, 2007
[Erdogamus05]
Hakan Erdogmus, Maurizio
Morisio, Marco Torchiano. On the
Effectiveness of the
Test-First Approach to
Programming. Proceedings of the
IEEE Transactions on Software
Engineering, 31(1). January 2005.
[Huettermann08] M. Huettermann. Agile Java Entwicklung in der Praxis, OReilly,
2008.
David S. Janzen. Software
[Janzen06]
Architecture Improvement
through Test Driven
Development, University of
Kansas, 2006,
http://www.acm.org/src/subpages/g
f_entries_06/DavidJanzen_src_gf0
6.pdf, 2009-04-06
Gerard Meszaro, xUnit
[Meszaro08]
Patterns.com, 2008,
http://xunitpatterns.com/test first
development.html, 2009-04-14
[Nagappan08]
Nagappan, N., E. M. Maximillien, T
Bhat, L Williams. Realizing quality
improvement through test driven
development: results and
experiences of four industrial
teams, Journal of Empirical
Software Engineering, 13:289-302,
2008
Roy Osherove. The Art Of Unit
[Osherove08]
Testing, Manning Publications,
2008,
http://www.manning.com/osherove/

SAP AG 2009

osherove_meapch1.pdf, 2009-0406
[RTCA/DO-178B] RTCA/DO-178B, Software
Considerations in Airborne
Systems and Equipment
Certification,
http://www.do178site.com/do178b_
structural_coverage.php, 2009-0415
Implementation of business object
[SAP09]
Purchase Order of the proxy
application Enterprise
Procurement Model (EPM), SAP,
2009,
\\production.wdf.sap.corp\depot\inf
o\NW_E_TI\Projects\Test Tools
Automation NW
Strategy\020_Code_Coverage\020
_Workpackages\MD30\_ALL\100_
CaseStudy_UnitTestImplementatio
n_EPM_PO.ppt, 2009-04-14
[Siniaalto06]
Maria Siniaalto. Agile Deliverable
D.2.7, Test driven
development: empirical body of
evidence,
Juergen Staader. Attention ABAP
[Staader05]
Developers! Boost the quality of
Your Programs by Writing
Automated Unit Tests with ABAP
Unit, SAP Professional Journal,
2005
[Williams03]
Laurie Williams, E. Michael
Maximilien, Mladen Vouk.TestDriven Development as a DefectReduction Practice, Proceedings of
the 14th International Symposium
on Software Reliability
Engineering, 2003, from
http://portal.acm.org/citation.cfm?id
=952364, 2009-04-16

Appendix
The following section only contains some
additional definitions which have been removed
from the paper.
The ANSI/IEEE standard for unit testing
[IEEE87] defines the term test unit as A set of
one or more computer program modules together
with associated control data, (for example, tables),
usage procedures, and operating procedures that
satisfy the following conditions:

All modules are from a single computer program

At least one of the new or changed modules in

the set has not completed the unit test

The set of modules together with its associated

data and procedures are the sole object of a
testing process

[Osherove08] gives a definition of a good unit

test in his book: A unit test is an automated piece
of code that invokes a different method and then
checks some assumptions about the logical
behaviour of that method or class under test. A
unit test is written using a unit testing framework. It
can be written easily and runs quickly. It can be
executed, repeatedly, by anyone on the
development team.
[Meszaro08] defines a unit test as A test that
verifies the behaviour of some small part of the
overall system. What makes a test a unit test is
that the system under test (SUT) is a very small
subset of the overall system and may be
unrecognizable to someone who is not involved in
building the software. The actual SUT may be as
small as a single object or method that is a
consequence of one or more design decisions
although its behaviour may also be traced back to
some aspect of the functional requirements. There
is no need for unit tests to be readable,
recognizable or verifiable by the customer or
business domain expert. Contrast this with a
customer test which is derived almost entirely from
the requirements and which should be verifiable by
the customer. In eXtreme Programming, unit tests
are also called developer tests or programmer
tests.
In Getting started with: Unit Testing
([Oracle04]) the authors state the following: A unit
test is a test of a distinct unit of functionality. A unit
SAP AG 2009

of functionality is not directly dependent on the

completion of another unit of functionality. Within a
Java application a unit of functionality is often (but
not always) a single method. Unit tests are the
finest level of granularity in testing.
The authors of Testing SAP Solutions say that
[] In the SAP project methodology, developer
tests are usually regarded as part of development
activity, and thus do not come under the heading
of functional [authors note: or feature] tests in its
more restricted sense. []. ([SAP07] p. 32)
The IEEE standard for unit testing defines
100% statement coverage per requirement
([IEEE87] p.10, section 3.1.2 (2)):
When testing a unit during software
development, every software feature must be
covered by a test case or an approved exception.
[] When testing a unit implemented with a
procedural language (for example, COBOL) during
software development, every instruction that can
be reached and executed must be covered by a
test case or an approved exception, except for
instructions contained in modules that have been
separately unit tested.

[IEEE87]

[Meszaro08]

[Oracle04]

[Osherove08]

[SAP07]

ANSI/IEEE. Standard for

Software Unit Testing, Std 10081987, 1987,
http://ieeexplore.ieee.org/xpls/abs_
all.jsp?arnumber=27763, 2009-0406
Gerard Meszaro, xUnit
Patterns.com, 2008,
http://xunitpatterns.com/unit
test.html, 2009-04-14
Jan Kettenis, Remco de Block.
Getting started with: unit-testing,
Oracle Corporation, 2004,
http://www.oracle.com/technology/
products/jdev/collateral/papers/10g
/GettingStartedWithUnitTesting.pdf
, 2009-04-06
Roy Osherove. The Art Of Unit
Testing, Manning Publications,
2008,
http://www.manning.com/osherove/
osherove_meapch1.pdf, 2009-0406
Markus Helfen, Michael Lauer,
hans Martin Trauthwein. Testing
SAP Solutions, SAP Press, 2007