Abap Future

First-hand knowledge.
Reading Sample
This sample chapter describes how to use ABAP Unit for test-driven
development (TDD) when creating and changing custom programs
to make your changes with minimal risk to the business. This chap-
ter explains what TDD is and how to enable it via the ABAP Unit
framework.
ABAP Unit and Test-Driven

Development
Contents
Index
The Author
Paul Hardy
ABAP to the Future
801 Pages, 2016, $79.95
ISBN 978-1-4932-1410-5
www.sap-press.com/4161
Code without tests is bad code. It doesnt matter how well-written it is; it
Chapter 3
doesnt matter how pretty or object-oriented or well-encapsulated it is.

With tests, we can change the behavior of our code quickly and verifiably.
Without them, we really don't know if our code is getting better or worse.
Michael Feathers, Working Effectively with Legacy Code
3 ABAP Unit and Test-Driven Development
Nothing is more important, during the process of creating and changing custom
programs, than figuring out how to make such changes with minimal risk to the
business. The way to do this is via test-driven development (TDD), and the tool to
use is ABAP Unit. This chapter explains what TDD is and how to enable it via the
ABAP Unit framework.
In the traditional development process, you write a new program or change an

existing one, and after youre finished you perform some basic tests, and then
you pass the program on to QA to do some proper testing. Often, there isnt
enough time, and this aspect of the software development lifecycle is brushed
overwith disastrous results. TDD, on the other hand, is the opposite of the tra-
ditional development process: You write your tests before creating or changing
the program. That turns the world on its head, which can make old-school devel-
opers heads spin and send them running for the door, screaming at the top of
their lungs. However, if they can summon the courage to stay in the room and
learn about TDD, then they will be a lot better off.
The whole aim of creating your tests first is to make it so that, once the tests have
all been written, as you createand more importantly changeyour application,
you can follow the menu path Program Test Unit Test at any given instant to
see a graphical display of whats currently working in your program and whats
either not yet created or broken (Figure 3.1). This way, when the time comes to
move the created or changed code into test, you can be confident that its correct.
159
3 ABAP Unit and Test-Driven Development Eliminating Dependencies 3.1
3.1 Eliminating Dependencies

In the US game show Jeopardy!, a contestants answer must be in the form of a
questionlike this:
Game show host: Something that stops you dead in your tracks when you want to
write a test.
Figure 3.1 ABAP Unit Results Screen
Contestant: What is a dependency?
Because thats a highly desirable outcome from everybodys perspective, this The contestant is correct. But to go into a little more detail, a dependency is what
chapter explains how to transform your existing code into test-driven code via you have when you want to do a test for your productive code but you cant
three main steps: because the productive code reads from the database or writes to the database or
accesses some external system or sends an email or needs some input from a user
1. Eliminating dependencies in your existing programs
or one of a million other things you cannot or do not want to do in the develop-
2. Implementing mock objects in your existing programs
ment environment.
3. Using ABAP Unit to write and implement test classes
As an example, consider a monolithic SAP program that schedules feeding time at
Each step will be covered in detail. After that, some additional advice on how to the zoo and makes sure all the animals get the right amount and type of food.
improve TDD via automated frameworks will be presented. Finally, the chapter Everything works fine. The keepers have some sort of mobile device that they can
will conclude with a look at how to run large numbers of unit tests on different query to see what animals need feeding next, and theres some sort of feedback
data sets without having to hard-code them all. they have to give after feeding the animals. They want to keep track of the food
inventory, and so on; none of the details are important for this example.
Unit Testing Procedural Programs
All is well until one day when they get two pandas on loan from China, and the
The examples in this chapter deal with testing object-oriented (OO) code (i.e., meth-
programmer has to make some changes to accommodate their specific panda-type
ods), and most of the examples of ABAP Unit you will find in books or on the web will
also focus on OO programming. This doesnt mean that you cant test procedural pro- needs (e.g., bamboo shoots) without messing up all the other animals. The pro-
grams; its far easier to test an OO program, but its not the end of the world to add unit grammer can do a unit test on the panda-specific changes he has made, but how
tests to a function module or a procedural program. can he be sure that an unforeseen side effect will not starve the lions, causing
You most likely have huge monolithic procedural programs in your system that it would them to break out and eat all the birds and all the monkeys before breaking into
be too difficult to rewrite in an OO fashion, because doing so would take a lot of time the insect house and crushing and eating the beehive?
and not provide any new functionality. In such cases, whenever you are called on to
maintain a section of that programfixing a bug or adding new functionalityyou can Normally, theres no way to do it; there are just too many dependencies. The
make relatively minor changes to break up the dependencies as described in this chap- program needs to read the system time, read the configuration details on what
ter, and then slowly add test methods to bring little islands of the program under test. animal gets fed when, read and write inventory levels, send messages to the zoo-
As time goes by, more and more islands of the program will have tests, making it more keepers, receive and process input from those same zookeepers, interface with
and more stable, until one day the whole archipelago of the program will be covered.
assorted external systems, and so on.
However, you really dont want to risk the existing system breaking, leading the
lions to dine on finch, chimps, and mushy bees, so how can we enable tests?
160 161
The first step is to break up the dependencies. In this section, youll learn how to WHEN 'Y'.
"Off we go!
do exactly that, a process that involves two basic steps:
WHEN 'N'.
RETURN.
1. Look at existing programs to identify sections of code that are dependencies
WHEN OTHERS.
(and are thus candidates to be replaced by mock objects during a test). RETURN.
ENDCASE.
2. Change your production code to separate out the concerns into smaller classes
that deal with each different type of dependency (well look at two ways of * Fire Missile
doing so: one quick and dirty, the other slower and more time-intensive but CALL FUNCTION 'TELL_PI_PROXY_TO_FIRE_MISSILE'.
ultimately more rewarding).
* Print Results
CALL FUNCTION 'PRINT_NUCLEAR_SMARTFORM'.
3.1.1 Identifying Dependencies ENDFORM."Fire Nuclear Missile

Listing 3.1 shows an example of a common ABAP application. In this case, our Listing 3.1 Common ABAP Application
good old friend the baron (remember him from the Introduction?) doesnt want
any neighboring mad scientists building monsters and thus encroaching on his In this code, you want to test two things:
market, so as soon as hears about such a competitor he drops a nuclear bomb on That you direct the missile to the correct target
him (as any good mad scientist would). Listing 3.1 illustrates this by first getting
That if the user aborts halfway through, the missile does not actually fire
the customizing settings for the missiles and making sure theyre ready to fire,
then confirming with the operator that he really wants to fire the missile, then fir- However, because of the way the routine is written, you cant do a meaningful
ing the missile, and finally printing out a statement saying that the missile was test unless the following points are true:
fired. At almost every point in the code, youll deal with something or somebody
You have an actual database with proper customizing data.
external to the SAP system: the database, the operator (user), the missile firing
system, and the printer. You have a link to the sensor on the missile.
You have a user to say yes or no.
FORM fire_nuclear_missile.
You actually fire the missile to see what happens (possibly resulting in the
* Read Database
world being destroyed).
CALL FUNCTION 'READ_CUSTOMIZING'.
* Query Missile Sensor You have a printer hooked up.
CALL FUNCTION 'GET_NUCLEAR_MISSILE_STATUS'.
These are all examples of dependencies. As long as theyre part of your code, you
* Business Logic
cant implement TDD.
IF something.
"We fire the missile here
Unfortunately, most ABAP code traditionally looks like the example in Listing
ELSEIF something_else.
"We fire the missile there Section 3.1. Thus, when preparing an existing program to be unit tested, the first
ENDIF. thing to do is make a list of anything that is not pure business logic (i.e., calls to
the database, user input, calls to external systems, etc.), exactly as in the preced-
* Ask user if he wants to fire the missile
CALL FUNCTION 'POPUP_TO_CONFIRM'. ing bullet list.
* Business Logic
CASE user_answer.
162 163
3.1.2 Breaking Up Dependencies Using Test Seams * ELSEIF something_else.

* "We fire the missile here
There are two ways to break up dependenciesquick and dirty versus slow and * ENDIF.
correctly. Often, the powers that be will force you into the quick and dirty
* Ask the user if they want to fire the missile
method, so in version 7.5 of ABAP, we now have test seams designed to make
TEST-SEAM user_input.
such dependencies testable without major surgery on the existing program. DATA: user_answer TYPE char01.
CALL FUNCTION 'POPUP_TO_CONFIRM'
This approach only works on function groups and global classes. Old function EXPORTING
groups often have lots of dependencies mixed in with the business logic, but it is titlebar = 'Missile Confirmation'
text_question = 'Do you want to launch the missile?'
horrifying if a global class gets into that state. If the code to be tested is in an exe-
text_button_1 = 'Yes'
cutable program or a module pool but can be quickly moved to such a construct text_button_2 = 'No'
(function group/global class), then test seams are worth a try. If theres a lot of default_button = '2'
IMPORTING
effort involved, then youre better off jumping straight to Section 3.1.3 and doing answer = user_answer2
some serious rearranging of the code. EXCEPTIONS
text_not_found = 1
Warning: Houston, We Have a Problem OTHERS = 2.
The TEST-SEAM concept should never be used in new programs, because its a dirty IF sy-subrc <> 0.
workaround that horrifies all serious programmers (they would say production code RETURN.
ENDIF.
should be unaware what parts of it are going to be tested) and is designed purely as an
interim measure to use while redesigning old, badly written programs.
END-TEST-SEAM.
* Some more business logic

In the example in this section, weve moved the whole program into a function
* You would want to test that saying "no" prevented the
module so you can see how to use test seams. Inside the function module, each * missile from firing
dependency is surrounded by a test seam with a unique name describing the CASE user_answer.
WHEN '1'.
dependency (Listing 3.2).
"Off We Go! Bombs Away!
FORM fire_nuclear_missile. WHEN '2'.
RETURN.
TEST-SEAM read_database. WHEN OTHERS.
* Here the dependency is needing an actual database with real data RETURN.
CALL FUNCTION 'ZREAD_MONSTER_CUSTOMIZING'. ENDCASE.
END-TEST-SEAM.
TEST-SEAM missile_interface.
TEST-SEAM missile_sensor. * Here the dependency is needing an actual missile to fire
* Here the dependency is needing contact with an actual missile system CALL FUNCTION 'ZTELL_PI_PROXY_TO_FIRE_MISSILE'.
CALL FUNCTION 'ZGET_NUCLEAR_MISSILE_STATUS'. END-TEST-SEAM.
END-TEST-SEAM.
TEST-SEAM printer.
* Actual Business Logic (that you want to test) * Here the dependency is needing an actual printer
* You would want to test that the missile gets sent to the right place CALL FUNCTION 'ZPRINT_NUCLEAR_SMARTFORM'.
* i.e., gets dropped on your enemy, not on you END-TEST-SEAM.
* IF something.
* "We fire the missile here ENDFORM. "fire_nuclear_missile
Listing 3.2 Surrounding Dependencies with Test Seams
164 165
Highlighting the dependencies in this way not only allows unit testing (as covered The next step is to change the production code to make calls to methods of these
in Section 3.3) but also saysin letters of fire a thousand miles highthat the newly created classes. The end result will look like Listing 3.3.
code is badly designed and needs changing, which, as mentioned earlier, youre
FORM fire_nuclear_missile.
often not allowed to do because the powers that be wrongly think such changes
are risky when they are the exact reverse. * Read Database
mo_database_access->read_customising( ).
mo_missile_interface->get_nuclear_missile_status( ).
3.1.3 Breaking Up Dependencies Properly * Business Logic
The correct way (once theyre identified) of breaking up dependencieswhich IF something.
"We fire the missile here
takes a lot of effortis redesigning your program so that it adopts a separation of
ELSEIF something_else.
concerns approach. This approach dictates that you have one class for database "We fire the missile there
access, one for the user interface layer, and one for talking to an external system; ENDIF.
that is, each class does one thing only and does it well. This is known as the single * Ask user if they want to fire the missile
responsibility principle. Designing an application this way enables you to change mo_user_interface->popup_to_confirm( ).
the implementation of, say, your user interface layer without affecting anything
* Business Logic
else. This type of breakup is vital for unit tests. CASE user_answer.
WHEN 'Y'.
Warning: Houston, We Have a Problem "Off we go!
WHEN 'N'.
As an aside and a warning, Ive seen a great example in which someone split out all the RETURN.
database access into its own class, presumably following the separation of concerns WHEN OTHERS.
model. However, that person also made every single variable and method staticand RETURN.
you cant subclass static methods. As a result, the end program still wasnt eligible for ENDCASE.
unit testing.
* Fire Missile
mo_missile_interface->tell_pi_proxy_to_fire_missile( ).
To illustrate the separation of concerns approach, take database access as an
* Print Results
example. This means that you would go through your program looking for every mo_printer->print_nuclear_smartform( )..
SELECT statement and extract them out in a method of a separate database access
class. Repeat the process for other functions of the programs, such as processing ENDFORM."Fire Nuclear Missile
user input, communicating with external systems, and anything else you can Listing 3.3 Calling Methods of Classes
identify as a dependency, each having one specific class that serves each such pur-
pose. (You may be wondering how to decide which functions need to be split into Note that the functionality has not been changed at all; the only difference is that
their own class. Luckily, this is an iterative process; when you start writing tests the calls to various external systems (the dependencies) are now handled by
and the test fails because it does not really have access to proper database entries, classes as opposed to functions or FORM routines. All that remains untouched is
user input, or an external system, it will become clear what is a dependency and the business logic.
thus needs to be isolated into its own class.) With the dependencies successfully eliminated, you can now implement mock
objects.
166 167
3 ABAP Unit and Test-Driven Development Implementing Mock Objects 3.2
3.2 Implementing Mock Objects METHOD fire_nuclear_missile."Test Method

TEST-INJECTION read_database.
* Set assorted variables, as if you had read them from the
After youve isolated each dependency into its own class, you can change your * actual database
existing programs to take advantage of the ABAP Unit framework. There are two END-TEST-INJECTION.
steps to this:
TEST-INJECTION user_input.
1. Create mock objects that appear to do the same thing as real objects dealing user_answer = '1'.
END-TEST-INJECTION.
with database access and the like, but which are actually harmless duplicates
solely for use in unit tests. PERFORM fire_nuclear_missile.
2. Make sure that all the classes under tests (often a unit test will use several ENDMETHOD.
classes, but there is always one main one that you are testingthe class under Listing 3.4 Test Injections for Test Seams
test) are able to use these mock objects instead of the real objects, but only
when a test is underway. This is known as injection. This works fine; a test injection can be empty and so no code is executed during
the test, so no database data is read, no missile is fired, and all is well.
Mock Objects vs. Stub Objects
This is all well and good but dont do it; its more trouble than its worth, and if
When talking about mock objects, the terms stub and mock are often used interchange-
ably; technically, though, there is a difference. If youre testing how your class affects an proper programmers catch you, theyll make you stand in the corner with a dunce
external system, then the fake external system is a mock, and if youre testing how the cap on your head. Instead, proceed according to the next section.
fake external system affects your class, then the fake external system is a stub. (Either
way, the point is that you use a fake external system for testing.)
3.2.2 Creating Mock Objects
Before jumping into creating mock objects and injection, lets first take a quick For testing purposes, what you actually want is to define mock classes and mock
look at test injection, introduced with test seams. This is not how you should objects. Mock classes are classes that run in the development environment. They
implement mock objects, but you should see it in action at least once before dis- dont really try to read and write to the database, send emails, fire nuclear mis-
missing it. siles, and so on, but they test the business logic nonetheless. Mock objects follow
the same principles as regular objects; that is, in the same way that a monster
object is an instance of the real monster class, a mock monster object is an
3.2.1 Test Injection for Test Seams instance of a mock monster class.
Test injection for test seams is the poor mans version of implementing mock
This is where the basic features of OO programming come into play: subclasses
objects. Instead of replacing entire routines with a duplicate inside a mock class,
and interfaces. To continue the previous example (about firing nuclear missiles),
you flag sections (one or more lines of code) inside of such routines as shown in
youll next create a subclass of the database access class that doesnt actually read
Section 3.1.2 so they can be replaced with different code during a test. In other
the database but instead redefines the database access methods to return hard-
words, you have the option to surround sections of production code with test
coded values based upon the values passed in. In Listing 3.5, youll see some pos-
seams. When the program runs in production, the actual code within the test
sible redefined implementations of methods in mock subclasses that could
seam is executed. When running a test, you define some bogus code that runs
replace the real classes in the example.
instead, the format of which is as shown in Listing 3.4.
METHOD read_customising. "mock database implementation
*--------------------------------------------------------------*
* IMPORTING input_value
168 169
3 ABAP Unit and Test-Driven Development Implementing Mock Objects 3.2
* EXPORTING export_vlaue 3.2.3 Proper Injection

*--------------------------------------------------------------*
CASE input_value. Usually, classes in your program make use of smaller classes that perform special-
WHEN one_value. ized functions. The normal way to set this up is to have those helper classes as pri-
export_value = something.
vate instance variables of the main class, as shown in Listing 3.6.
WHEN another_value.
export_value = something_else.
CLASS lcl_monster_simulator DEFINITION.
WHEN OTHERS.
export_value = something_else_again.
PRIVATE SECTION.
ENDCASE.
DATA:
ENDMETHOD. "read customising mock database implementation
"Helper class for database access
mo_pers_layer TYPE REF TO zcl_monster_pers_layer,
METHOD popup_to_confirm. "mock user interface implementation
"Helper class for logging
*--------------------------------------------------------------*
mo_logger TYPE REF TO zcl_logger.
* RETURNING rd_answer TYPE char01
*--------------------------------------------------------------*
ENDCLASS.
rd_answer = '1'.Yes
Listing 3.6 Helper Classes as Private Instance Variables of Main Class
ENDMETHOD. "mock user interface implementation
These variables are then set up during construction of the object instance, as
METHOD fire_missile. "Mock External Interface Implementation
shown in Listing 3.7.
* Don't do ANYTHING - it's just a test
METHOD constructor.
ENDMETHOD. "Fire Missile - Mock Ext Interface - Implementation
CREATE OBJECT mo_logger.
Listing 3.5 Mock Method Redefinitions of Assorted Real Methods
CREATE OBJECT mo_pers_layer
In this example, you create subclasses of your database access class, your user EXPORTING
io_logger = mo_logger " Logging Class
interface class, and your external system interface class. Then, you redefine the id_valid_on = sy-datum. " Validaty Date
methods in the subclasses such that they either do nothing at all or return some
hard-coded values. ENDMETHOD. "constructor
Listing 3.7 Variables Set Up during Construction of Object Instance
Object-Oriented Recommendation
However, as you can see, this design does not include any mock objects, which
In order to follow one of the core OO recommendationsto favor composition over
inheritanceyou should create an interface thats used by your real database access
means that you have no chance to run unit tests against the class. To solve this
class and also have the mock class be a subclass that implements that interface. In the problem, you need a way to get the mock objects you created earlier inside the
latter case, before ABAP 7.4, youd have to create blank implementations for the meth- class under test. The best time to do this is when an instance of the class under
ods you are not going to use, and that could be viewed as extra effort. Nevertheless, test is being created.
interfaces are a really Good Thing and actually save you effort in the long run. Once you
read books like Head First Design Patterns (see the Recommended Reading box at the When creating an instance of the class under test, you use a technique called con-
end of the chapter), youll wonder how you ever lived without building up class defini- structor injection to make the code use the mock objects so that it behaves differ-
tions using interfaces. ently than it would when running productively. With this technique, you still
have private instance variables of the database access classes (for example), but
170 171
3 ABAP Unit and Test-Driven Development Writing and Implementing Unit Tests 3.3
now you make these into optional import parameters of the constructor. The con-
you pass in a fake object that gives hard-coded values. Now, say a requirement comes
structor definition and implementation now looks like the code in Listing 3.8. in that the users want to change some of the configuration values on screen and run a
PUBLIC SECTION. what-if analysis before saving the changes. One way to do that is to have a subclass that
METHODS: constructor IMPORTING uses the internal tables in memory as opposed to the ones in the database, and you pass
io_pers_layer TYPE REF TO zcl_monster_pers_layer OPTIONAL that class into the constructor when running your simulator program in what-if mode.
io_logger TYPE REF TO zcl_logger OPTIONAL.
METHOD constructor."Implementation At this point, you now have mock objects and a way to pass them into your pro-
gram. This means that youre ready to write the unit tests.
IF io_logger IS SUPPLIED.
mo_logger = io_logger.
ELSE.
CREATE OBJECT mo_logger.
ENDIF.
3.3 Writing and Implementing Unit Tests
IF io_pers_layer IS SUPPLIED. At last, the time has come to talk about actually writing the test classes and how
mo_pers_layer = io_pers_layer. to use the ABAP Unit framework. In this section, youll walk through this process,
ELSE.
which involves two main steps:
CREATE OBJECT mo_pers_layer
EXPORTING
1. Set up the definition of a test class. The definition section of a class, as always,
io_logger = mo_logger " Logging Class
id_valid_on = sy-datum. " Validity Date is concerned with the what, as in, What should a test class do? This is covered
ENDIF. in Section 3.3.1.
ENDMETHOD."constructor implementation 2. Implement a test class. Once you know what a test class is supposed to do, you
Listing 3.8 Constructor Definition and Implementation can go into the detail of how its achieved technically. This is covered in Section
3.3.2.
The whole idea here is that the constructor has optional parameters for the vari-
ous classes. The main class needs these parameters in order to read the database, Executable Specifications
write to a log, or communicate with any other external party thats needed. When Some people in the IT world like to call unit tests executable specifications, because they
running a unit test, you pass in (inject) mock objects into the constructor that sim- involve the process of taking the specification document, breaking it down into tests,
ply pass back hard-coded values of some sort or dont do anything at all. (In the and then, when the program is finished, executing these tests. If they pass, then you are
proving beyond doubt that the finished program agrees with the specification. If you
real production code, you dont pass anything into the optional parameters of the
cant break the specification into tests, then it means that the specification is not clear
constructor, so the real objects that do real work are created.) enough to turn into a program. (Actually, most specifications I get fall into that cate-
gory. But to be fair to the business analysts, there is only so much that you can write on
Arguments Against Constructor Injection the back of a post-it note.)
Some people have complained that the whole idea of constructor injection is horrible,
because a program can pass in other database access subclasses when executing the
3.3.1 Defining Test Classes
code for real outside of the testing framework. However, I disagree with that argument,
because constructor injection can give you benefits outside of unit testing. There are several things you need to define in a test class, and the following sub-
As an example, consider a case in which a program usually reads the entire monster- sections will go through them one by one. Broadly, the main steps in defining
making configuration from the databaseunless youre performing unit testing, when your test class are as follows:
172 173
1. Enable testing of private methods. CLASS lcl_test_class DEFINITION FOR TESTING

RISK LEVEL HARMLESS
2. Establish the general settings for a test class definition. DURATION SHORT
FINAL.
3. Declare data definitions.
Listing 3.10 Test Class General Settings
4. Set up unit tests.
5. Define the actual test methods. Lets take this one line at a time. In the first line, you tell the system this is a test
6. Implement helper methods. class and thus should be invoked whenever youre in your program and select the
Unit Test option from whichever tool youre in (the menu path is subtly different
Start the ball rolling by creating a test class. Start with a global Z class that youve depending on which transaction you are in).
defined, and open it in change mode via SE24 or SE80. In this global class, follow
the menu option Goto Local Definitions Implementations Local Test Now, you come to RISK LEVEL. For each system, you can assign the maximum per-
Class. mitted risk level. Although unit tests never run in production, its possible for
them to run in QA or development. By defining a risk level, you could, for exam-
ple, make it so that tests with a DANGEROUS risk level cant run in QA but can run
Enabling Testing of Private Methods in development. (Leaving aside that I feel unit tests should only be run in devel-
To begin, enable testing of private methods. The initial screen shows just a blank opment, how could a unit test be dangerous? I can only presume its dangerous if
page with a single comment, starting with use this source file. In Listing 3.9, it really does alter the state of the database or fire a nuclear missile. Try as I might,
you add not only the normal definition line but also a line about FRIENDS; this is I cant think why I would want a test that was dangerous. Tests are supposed to
the line that enables you to test the private methods of your main class. In the fol- stop my real program being dangerous, not make things worse. Therefore, I
lowing example, the global class youll be testing is the monster simulator, and always set this value to HARMLESS, which is what the tests I write are.)
the only way you can test its private methods is if you make it friends with the
Next is DURATIONhow long you think the test will take to run. This is intended
test class.
to mirror the TIME OUT dump you get in the real system when a program goes into
*"* use this source file for your ABAP unit test classes an endless loop or does a full table scan on the biggest table in the database. You
CLASS lcl_test_class DEFINITION DEFERRED.
can set up the expected time periods in a configuration transaction.
"Need to make the class under test "friends" with the test class
How long should those time periods be? Well, Ill tell you how long I think a unit
"in order to enable testing for private methods
CLASS zcl_monster_simulator DEFINITION LOCAL FRIENDS lcl_test_class. test should take to run: It should be so fast that a human cannot even think of a
Listing 3.9 Defining Test Class time period so small. The whole point of unit tests is that you can have a massive
amount of them and not be afraid to run the whole lot after youve changed even
A lot of people say that testing private classes is evil and that you should only test one line of code. Its like the syntax check; most developers run that all the time,
the methods the outside world can see. However, over the course of time so but they wouldnt if it took ten minutes. Hopefully, the only reason a unit test
many bugs have been found in any method at all, be it public or private, that you would take a minute or more to run is if it actually did read the database or pro-
should have the option to test anything you feel like. cess a gigantic internal table in an inefficient way. If you are worried about the
method under test going into an endless loop or about having to process a really
huge internal tablesequencing a human genome or somethingthen you could
General Settings for a Test Class Definition
set the DURATION to LONG, and it would fail due to a time out. Thus far, though, I
Once youve created the class, its time to establish the general settings for the have never found a reason to set it to anything other than SHORT.
class, as shown in Listing 3.10.
174 175
Declaring Data Definitions ms_input_data TYPE zvcs_monster_input_data,

mt_bom_data TYPE ztt_monster_items,
Continuing with the definition of your test class, youve now come to the data md_creator TYPE zde_monster_creator_name.
declarations. The first and most important variable you declare will be a variable Listing 3.12 Variables for Test Class Definition
to hold an instance of the class under test (a main class from the application
youre testing various parts of). After defining the data, you now need to say what methods are going to be in the
test class.
This class, in accordance with good OO design principles, will be composed of
smaller classes that perform specific jobs, such as talking to the database. In this
example, when the application runs in real life, you want to read the database and Defining the SETUP Method
output a log of the calculations for the user to see. In a unit test, you want to do
The first method to define is always the SETUP method, which resets the system
neither. Luckily, your application will be designed to use the injection process
state so that every test method behaves as if it were the first test method to be
described in Section 3.2.3 to take in a database layer and a logger as constructor
run. Therefore, any of those evil global variables knocking about must either be
parameters, so you can pass in mock objects that will pretend to handle interac-
cleared or set to a certain value, and the class under test must be created anew.
tions with the database and logging mechanism. As youre going to be passing in
This is to avoid the so-called temporal coupling, in which the result of one test
such mock objects to a constructor, you need to declare instance variables based
could be influenced by the result of another test. That situation would cause tests
on those mock classes (Listing 3.11).
to pass and fail seemingly at random, and you wouldnt know if you were coming
PUBLIC SECTION. or going.
PRIVATE SECTION. This method cant have any parametersyoull get an error if you try to give it
DATA: mo_class_under_test TYPE REF TO zcl_monster_simulator, anybecause it must perform the exact same task each time it runs and importing
mo_mock_pers_layer TYPE REF TO zcl_mock_pers_layer,
mo_logger TYPE REF TO zcl_mock_logger. parameters might change its behavior. The code for defining the SETUP method is
Listing 3.11 Defining Mock Classes for Injecting into Test Class very simple:
METHODS: setup,
In Listing 3.8, you saw how in the constructor in production, the class would cre-
ate the real classes, but during a unit test mock classes are passed into the con-
Defining the Test Methods
structor of the class under test by the SETUP method, which runs at the start of
each test method. After defining the SETUP method, youll move onto defining the actual test meth-
ods. At this stage, you havent actually written any production code (i.e., the code
The full list of the data definitions in the test class are shown in Listing 3.12. In that will run in the real application), and all you have is the specification. There-
addition to the mock classes, there are some global (to a class instance) variables fore, next youre going to create some method definitions with names that will be
for things such as the input data and the result. Its good to set things up this way recognizable to the person who wrote the specification (Listing 3.13). The FOR
because passing parameters in and out of test methods can distract someone look- TESTING addition after the method definition says that this method will be run
ing at the code (e.g., a business expert) from making sure that the names of the every time you want to run automated tests against your application.
test methods reflect whats supposed to be tested.
return_a_bom_for_a_monster FOR TESTING
PRIVATE SECTION. make_the_monster_sing FOR TESTING
DATA: mo_class_under_test TYPE REF TO zcl_monster_simulator, make_the_monster_dance FOR TESTING
mo_mock_pers_layer TYPE REF TO zcl_mock_monster_pers_layer, make_the_monster_go_to_france FOR TESTING
mo_mock_logger TYPE REF TO zcl_mock_logger, Listing 3.13 Unit Test Methods
176 177
These are the aims of the program to be written (sometimes these are called use really long test method names, like It Should Return a BOM for a Purple Monster,
cases); you want to be sure the application can perform every one of these func- but in ABAP you cant afford to add the extra characters of IT SHOULD to the
tions and perform them without errors. This is why you need unit tests. method name. Instead, you can put the IT SHOULD in a comment line with dots
after it, padding the comment line out to thirty characters to make it really obvi-
ous what the maximum permitted length of the names of the test methods are.
Implementing Helper Methods
You will then declare the test methods underneath the dotted line, being aware of
The last step in defining the test class is to implement helper methods (i.e., meth- when youre running out of space for the name. An example is shown in Listing
ods in your test class definition without the FOR TESTING addition). These are nor- 3.14.
mal private methods that are called by the test methods.
*--------------------------------------------------------------*
The purpose of helper methods is to perform low-level tasks for one or more of * Specifications
*--------------------------------------------------------------*
the actual test methods; in normal classes, public methods usually contain several
"IT SHOULD.....................
small private methods for the same reason. Helper methods usually fall into two "User Acceptance Tests
categories: return_a_bom_for_a_monster FOR TESTING,
make_the_monster_sing FOR TESTING
1. Helper methods that contain boilerplate code that you want to hide away make_the_monster_dance FOR TESTING
make_the_monster_go_to_france FOR TESTING
(because although you need this code to make the test work, it could be a dis-
Listing 3.14 Test Methods That Describe What an Application Should Do
traction to someone trying to understand the test)
2. Helper methods that call one or more ABAP statements for the sole purpose of
Other Names for Behavior-Driven Development
making the core test method read like plain English
Sometimes, these sorts of behavior-driven development unit tests are described as user
Inside each unit test method (the methods that end with FOR TESTING), you will acceptance tests. Although there is no actual user involved, the reason for the terminol-
have several helper methods with names that have come straight out of the spec- ogy is that this sort of test simulates the program exhibiting a behavior that the user
ification. As an example, the specification document says that the main purpose would expect when he performs a certain action within the program. Outside of SAP,
of the program is to return a bill of materials (BOM) for a monster, and you do the testing framework called FitNesse describes itself as such an automated user accep-
tance testing framework.
that by having the user enter various desired monster criteria, which are then
used to calculate the BOM according to certain rules. You may also see behavior-driven development referred to as the assemble/act/assert
way of testing (which doesnt read as much like natural language, but it makes some
Helper methods have names that adhere to a concept known as behavior-driven people very happy, because every word starts with the same letter).
development, the idea that tests should be managed by both business experts and
developers. When using behavior-driven development, the general recommenda- Whatever you want to call these types of automated tests, they usually involve
tion is to start all the test methods with IT SHOULD, with the IT referring to the several methodsand often several classes as wellall working together, as
application being tested (the class under test). Thus, you would have names such shown in Listing 3.15.
as IT SHOULD FIRE A NUCLEAR MISSILE, such names coming straight out of the spec-
*--------------------------------------------------------------*
ification that describes what the program is supposed to achieve. * Low-Level Test Implementation Methods
*--------------------------------------------------------------*
In ABAP, you are limited to thirty characters for names of methods, variables, "GIVEN.........................
database tables, and so onso you have to use abbreviations, which potentially given_monster_details_entered,
makes ABAP less readable than languages like Java. In Java, you would have
178 179
"WHEN.......................... The steps for implementing the test classes are as follows:
when_bom_is_calculated,
"THEN.......................... 1. Setting up the test
then_resulting_bom_is_correct,
2. Preparing the test data
Listing 3.15 The GIVEN/WHEN/THEN Pattern for Unit Tests
3. Calling the production code to be tested
As you can see in the preceding code, unit test methods that follow the behavior- 4. Evaluating the test result
driven development approach have three parts:
1. GIVEN describes the state of the system just before the test to be run. Step 1: Setting Up the Test
2. WHEN calls the actual production code you want to test. Our class under test has lots of small objects that need to be passed into it. For the
3. THEN uses ASSERT methods to test the state of the system after the class under first example, youll manually create all those small objects and pass them into
test has been run. the constructor method of the class under test to get the general idea of construc-
tor injection. Later on, youll find out how to reduce the amount of code needed
Use Natural Language to do this.
A test method is supposed to be able to be viewed by business experts to see if the test As theres no guarantee about the order in which the test methods will run, you
matches their specifications, so it has to read like natural language. Often, if business
want every test method to run as if it were the first test method run, to avoid tests
experts see even one line of ABAP, their eyes glaze over and youve lost them for good.
affecting each other. Therefore, when setting up the test, you create each object
instance anew and clear all the horrible global variables, as shown in Listing 3.17.
3.3.2 Implementing Test Classes
METHOD: setup.
Now that youve defined the test class, you can go ahead with the process of *-------------------------------------------------------*
implementing it. At the end of this step, youll be able to show the business * Called before every test
*-------------------------------------------------------*
expert who wrote the initial specification that youve made the specification into CREATE OBJECT mo_mock_logger.
a program that does what it says on the side of the box. CREATE OBJECT mo_mock_monster_pers_layer
EXPORTING
Given this, each implementation of a test method should look like it jumped io_logger = mo_logger
straight out of the pages of the specification and landed inside the ABAP Editor id_valid_on = sy-datum.
(Listing 3.16). CREATE OBJECT mo_class_under_test

EXPORTING
METHOD return_a_bom_for_a_monster.
id_creator = md_creator
io_pers_layer = mo_mock_pers_layer
given_monster_details_entered( ).
io_logger = mo_mock_logger.
when_bom_is_calculated( ).
CLEAR: ms_input_data,
md_creator.
then_resulting_bom_is_correct( ).
ENDMETHOD. "setup
ENDMETHOD. "Return a BOM for a Monster (Test Class)
Listing 3.17 Create Class under Test and Clear Global Variables
Listing 3.16 Implementation of Test Class
180 181
At this point, you can be sure that during the test you wont actually read the "WHEN..........................
METHOD when_bom_is_calculated.
database or output any sort of log, so you can proceed with the guts of the actual
tests, which can be divided into the three remaining steps: preparing the test mo_class_under_test->simulate_monster_bom(
data, calling the production code to be tested, and evaluating the test result. EXPORTING is_bom_input_data = ms_input_data
IMPORTING et_bom_data = mt_bom_data ).
ENDMETHOD."when_bom_is_calculated
Step 2: Preparing the Test Data
Listing 3.19 Calling Production Code to be Tested
You now want to create some test data to be used by the method being tested. In
real life, these values could come from user input or an external system. Here, The method that calls the code to be tested should be very shortfor example, a
youll just hard-code them (Listing 3.18). Such input data is often taken from real call to a single function module or a methodfor two reasons:
problems that actually occurred in production; for example, a user might have
said, When I created a monster using these values, everything broke down. 1. Clarity
There could be a large number of values, which is why you hide away the details Anyone reading the test code should be able to tell exactly what the input data
of the data preparation in a separate method, to avoid distracting anybody read- is, what routine processes this data, and what form the result data comes back
ing the main test method. in. Calling several methods in a row distracts someone reading the code and
makes them have to spend extra time working out whats going on.
METHOD given_monster_details_entered.
2. Ease of maintenance
ms_input_data-monster_strength = 'HIGH'. You want to hide the implementation details of whats being tested from the
ms_input_data-monster_brain_size = 'SMALL'.
test method; this way, even if those implementation details change, the test
ms_input_data-monster_sanity = 0.
ms_input_data-monster_height_in_feet = 9. method doesnt need to change.
md_creator = 'BARON FRANKENSTEIN'. For example, in a procedural program, you might call two or three PERFORM state-
ments in a row when it would be better to call a single FORM routineso that if
ENDMETHOD."Monster Details Entered Implementation
you were to add another FORM routine in the real program, you wouldnt have to
Listing 3.18 Preparing Test Data by Simulating External Input
go and add it to the test method as well. With procedural programs, it would be
good to have a signature with the input and output values, but a lot of procedural
Step 3: Calling the Production Code to be Tested programs work by having all the data in global variables. Such a program can still
The time has come to actually invoke the code to be tested; youre calling pre- benefit from unit testing; it just requires more effort (possibly a lot more effort) in
cisely one method (or other type of routine), into which you pass in your hard- setting up the test to make sure the global variables are in the correct state before
coded dummy values and (usually) get some sort of result back. the test is run.
The important thing is that the routine being called doesnt know its being called
from a test method; the business logic behaves exactly as it would in production, Step 4: Evaluating the Test Result
with the exception that when it interacts with the database or another external Once you have some results back, youll want to see if they are correct or not.
system its really dealing with mock classes. There are generally two types of tests:
In this example, when you pass in the hard-coded input data, the real business 1. Absolutely basic tests
logic will be executed, and a list of monster components is passed back (Listing In Chapter 6, Section 6.3, youll read about design by contract, which says what
3.19). a method absolutely needs before it can work and what it absolutely must do.
182 183
In their book The Pragmatic Programmer, Andrew Hunt and David Thomas state
when_bom_is_calculated( ).
that unit tests should test for method failures in terms of contract violations;
for example, do you pass a negative number into a method to calculate a square then_resulting_bom_is_correct( ).
root of that number (which is silly) or pass a monster with no head into a
CATCH zcx_violated_precondition.
method to evaluate hat size (a more realistic example)?
cl_abap_unit_assert=>fail( 'Violated Contract Precondition' ).
2. Data validation tests CATCH zcx_violated_postcondition.
cl_abap_unit_assert=>fail( 'Violated Contract Postcondition' ).
This is what most people would call the normal type of unit test in which you
ENDTRY.
have an expected result given a known set of inputs; for example, a method to
calculate the square root of sixteen should return four or (back in the real ENDMETHOD."Return a BOM for a Monster (Test Class)
world), when calling a method to supply monster hats, the HATS_RECIEVED Listing 3.20 Unit Test to Check for Basic Errors
returning parameter should be seven when the MONSTER_HEADS importing
parameter is seven, as demonstrated in the famous movie Seven Heads for The structure in Listing 3.20 is totally generic. In TDD, you create the structure
Seven Monsters. before writing the actual code, so the nature of the pre- and postconditions will
only be determined later. In this example, the precondition could be that the
Next, youll learn how to test for really basic failures, the standard way of evalu-
input data should be asking for sensible values, like wanting a murderous evil
ating test results, and how you can enhance the standard framework when the
monster as opposed to a cute fluffy one, and the postcondition should be that the
standard mechanism doesnt do everything you want. Finally, youll see how to
resulting monster is scary and not colored pink.
achieve 100% test coverage.
Evaluating Test Results in the Normal Way
Testing for Really Basic Failures
Moving on to looking at return values, when you ran the test method that called
In Chapter 6, youll see that each routine in a program has a contract with the
the production code, either you got a result backtable MT_BOM_DATA in the exam-
code that calls it, and there are only two ways of violating that contract: Either the
ple in Listing 3.21or some sort of publicly accessible member variable of the
calling program is at fault because the input data is wrong (violated precondition)
class under test was updateda status variable, perhaps. Next, youll want to run
or the routine itself is at fault because the data returned is wrong (violated post-
one or more queries to see if the new state of the application is what you expect
condition).
it to be in the scenario youre testing. This is done by looking at one or more vari-
The idea is that this contract is used to define unit tests for the routine, and those able values and performing an evaluation (called an assertion) to compare the
tests are used to verify that the routine is behaving correctly; two sides of the actual value with the expected value. If the two values dont match, then the test
same coin. fails, and you specify the error message to be shown to the person running the
test (Listing 3.21).
A failure of such a test indicates a really serious, fatal, end of the universe as we
know it type of bug, which needs to be addressed before dealing with minor (in "THEN..........................
METHOD then_resulting_bom_is_correct.
comparison) matters, like your program adding up one and one and getting three.
Listing 3.20 shows how to code such tests. DATA(bom_item_details) = mt_bom_data[ 1 ].
METHOD return_a_bom_for_a_monster. cl_abap_unit_assert=>assert_equals(

act = bom_item_details-part_quantity
TRY. exp = 1
msg = 'Monster has wrong number of Heads'
given_monster_details_entered( ). quit = if_aunit_constants=>no ).
184 185
Defining Custom Evaluations of Test Results

bom_item_details = mt_bom_data[ 2 ].
The methods supplied inside CL_ABAP_UNIT_ASSERT are fine in 99% of cases, but
cl_abap_unit_assert=>assert_equals( note that there is an ASSERT_THAT option that lets you define your own type of test
act = bom_item_details-part_quantity on the result. Lets look at an example of the specialized assertion ASSERT_THAT in
exp = 2
action. First, create a local class that implements the interface needed when using
msg = 'Monster has wrong number of Arms'
quit = if_aunit_constants=>no ). the ASSERT_THAT method (Listing 3.22).
bom_item_details = mt_bom_data[ 3 ]. CLASS lcl_my_constraint DEFINITION.
cl_abap_unit_assert=>assert_equals( act = bom_item_details-part_ PUBLIC SECTION.

quantity INTERFACES if_constraint.
exp = 1
msg = 'Monster has wrong number of Legs' ENDCLASS. "lcl_my_constraint DEFINITION
quit = if_aunit_constants=>no ). Listing 3.22 ASSERT_THAT
ENDMETHOD."Then Resulting BOM is correct Implementation

You have to implement both methods in the interface (naturally); one performs
Listing 3.21 Using Assertions to Check If Test Passed
whatever tests you feel like on the data being passed in, and the other wants a
detailed message back saying what went wrong in the event of failure. In real life,
When evaluating the result, you use the standard CL_ABAP_UNIT_ASSERT class,
you would have a member variable to pass information from the check method to
which can execute a broad range of tests, not just test for equality; for example,
the result method, but the example shown in Listing 3.23 just demonstrates the
you can test if a number is between five and ten. Theres no need to go into all the
basic principle.
options here; its easier if you just look at the class definition in SE24. (For a bit
more about ASSERT, see the box ahead.) CLASS lcl_my_constraint IMPLEMENTATION.
METHOD if_constraint~is_valid.
Multiple Evaluations (Assertions) in One Test Method
*--------------------------------------------------------*
Many authors writing about TDD have stated that you should have only one ASSERT * IMPORTING data_object TYPE data
* RETURNING result TYPE abap_bool
statement per test. As an example, you shouldnt have a test method that tests that the
*--------------------------------------------------------*
correct day of the week is calculated for a given date and at the same time tests whether
* Local Variables
an error is raised if you dont supply a date. By using only one ASSERT statement per DATA: monster_description TYPE string.
test, its easier for you to quickly drill down into whats going wrong.
I would change that rule slightly, so that youre only testing one outcome per test. monster_description = data_object.
Although your test might need several ASSERT statements to make sure its correct, the
result = abap_false.
fact that you are only testing one outcome will still make it easy to figure out whats
wrong. The default behavior in a unit test in ABAP, however, is to stop the test method CHECK monster_description CS 'SCARY'.
at the first failed assertion and not even execute subsequent assertions within the same CHECK strlen( monster_description ) GT 5.
method. Every test method will be called, even if some failbut only the first assertion CHECK monster_description NS 'FLUFFY'.
in each method will be checked.
result = abap_true.
You can avoid this problem by setting an input parameter. In Listing 3.21, there are
three assertions. By adding the following code, you can make the method continue with ENDMETHOD. "IF_CONSTRAINT~is_valid
subsequent assertions even if one fails:
quit = if_aunit_constants=>no
186 187
3 ABAP Unit and Test-Driven Development Automating the Test Process 3.4
3.4 Automating the Test Process

METHOD if_constraint~get_description.
*--------------------------------------------------------*
* RETURNING result TYPE string_table
In the example presented in this chapter, the code was deliberately simple in
*--------------------------------------------------------* order to highlight the basic principles without getting bogged down with unnec-
essary detail. However, in the real world programs are never simple. Even if they
DATA(error_message) = 'Monster is not really that scary'.
start off simple, they keep growing and mutating, the ground of the original pur-
APPEND error_message TO result. pose becoming buried under the ever-falling snow of new functionality.
ENDMETHOD. "IF_CONSTRAINT~get_description If you think about what youve read above, youll see that this can lead to quite a
large effort in writing the test code, in two areas:
ENDCLASS."My Constraint - Implementation
Listing 3.23 Implementation of a Custom Constraint Class 1. Setting up the class under test via the SETUP method
Well-designed OO programs use lots of small reusable classes, and these often
All that remains is to call the assertion in the THEN part of a test method, as shown need to be inserted into the main class during construction. The smaller classes
in Listing 3.24. often need still smaller classes inserted into them during their construction,
and so on. In practical terms, this can mean a lot of lines of code to build up
DATA(custom_constraint) = NEW lcl_my_constraint( ).
your test class, passing in assorted mock doubles and elementary data parame-
cl_abap_unit_assert=>assert_that( exp = custom_constraint ters, such as date, and organizational elements, such as plant or sales organiza-
act = scariness_description ).
tion.
Listing 3.24 Call Assertion
2. Creating mock objects
As you can see, the only limit on what sort of evaluations you can run on the test Although you need mock objects to take the place of real objects during a test
results is your own imagination. in order to avoid actual database access and the like, it can take a good deal of
effort to create these and to write the logic inside them to return hard-coded
Achieving 100 Percent Test Coverage values. Even worse, if youre passing in constructor objects as interfaces as
When evaluating your results, you want to make sure that youve achieved 100% opposed to actual classes (which all the OO experts recommend), then you
test coverage. In the same way that the US army wants no man left behind, you need to expend even more effort, because you have to create an implementa-
want no line of code to remain untested. That is, if you have an IF statement with tion for every method in your mock object that uses the interface, including the
lots of ELSE clauses or a CASE statement with 10 different branches, then you want methods youre not interested in.
your tests to ensure that every possible path is followed at some point during the Luckily, there are solutions for both problems and ahead, youll read about two
execution of the test classes to be sure that nothing ends in tears by causing an frameworks to solve those problems:
error of some sort.
A framework to automate dependency injection (which I created myself)
Thats not as easy as it sounds. Aside from the fact that you need a lot of tests,
A framework to automate creating mock objects (SAP standard)
how can you be sure you havent forgotten some branches? Luckily, theres tool
support for this. As of release 7.31 of ABAP, you can follow the menu path Local Then, youll see how to combine both techniques. The section will end with a
Test Classes Execute Execute Tests With Code Coverage. As mentioned look at what to do when you have a really large number of situations to test for,
earlier in the book, the same feature is available through ABAP in Eclipse. which is often the case.
188 189
Mock Objects Framework class needs to create itself and by creating and passing those objects in all at once.
This will drastically reduce the amount of CREATE OBJECT statementsand
Prior to ABAP 7.4 SPS 9, the only framework available to automate mock object cre-
because youre going to be using a program to dynamically determine what
ation was the open-source framework MockA (see Recommended Reading at the end of
the chapter). objects need to be created, that same program might as well also dynamically
Since then, SAP has introduced its own standard framework to fill that gap, which is
determine what type (subclass) those created objects should be.
described in this chapter. Listing 3.25 is an example of this approach; this code attempts to achieve the
same thing as the SETUP method in Listing 3.17, but with fewer CREATE OBJECT
statements. If you look at the definition of the SETUP method earlier in the chap-
3.4.1 Automating Dependency Injection ter, youll see three CREATE OBJECT statements, and in each case the object youre
Lets say, for the sake of example, that the main class under test needs two object creating has to be defined by a DATA statement. (Some objects also need data
instances to be passed into it during construction, and one of those objects needs parameters that are elementary, my dear Watson.)
some parameters itself. In other words, the main class has dependencies: The main
Listing 3.25 rewrites the same SETUP method, using a Z class created to use depen-
class depends on the fact that those object instances need to be created before it
dency injection. Look at this like a newspaper: Look at the four high-level method
itself can be created.
calls first (which represent the headlines), and then dive into the implementation
In real life, this could lead to dozens of lines of code in your SETUP method, cre- of each component method (representing the actual newspaper article) one at a
ating objects all over the place. This is bad, because the more CREATE OBJECT state- time.
ments you have in your program, the less flexible it becomes. The logic goes as
First, set some values for elementary data parameters. Then, specify any sub-
follows: Creating an object via CREATE OBJECT forces the resulting instance to be
classes you want to substitute for real classes. Finally, create an instance of the
of a specific class. Having objects of a specific class makes your program less resis-
class under test.
tant to change. If your main class contains lots of little helper classesas it
shouldthen you may need to have a great deal of CREATE OBJECT statements, "Set values for any elementary parameters that the objects
meaning that your program is full of rigid components. "being created need
zcl_bc_injector=>during_construction( :
This leads to two problems: First, you have to clutter up your code with a large for_parameter = 'ID_CREATOR' use_value = md_creator ),
for_parameter = 'ID_VALID_ON' use_value = sy-datum ).
number of CREATE OBJECT statements. Second, those CREATE OBJECT statements
usually create instances of a hard-coded class type rather than a dynamically "We want to use a test double for the database object
determined subclass. zcl_bc_injector=>instead_of(
using_main_class = 'ZCL_MONSTER_SIM_PERS_LAYER'
Now, youre always going to have to state the specific subclass you want some- use_sub_class = 'ZCL_MOCK_MONSTER_PERS_LAYER' ).
where. However, youll see that its possible to decouple this from the exact "Same deal for the logger
instant you call the CREATE OBJECT statement and, as a beneficial by-product, have zcl_bc_injector=>instead_of(
fewer CREATE OBJECT statements in the first place. using_main_class = 'ZCL_MONSTER_LOGGER'
use_sub_class = 'ZCL_MOCK_LOGGER' ).
The process of passing the objects a class needs to create itself is known as depen-
"Off we go!
dency injection; you saw this at work in Section 3.2.3 when you manually passed zcl_bc_injector=>create_via_injection(
mock objects into a constructor method. Here, you seek to automate the process CHANGING co_object = mo_class_under_test ).
by dynamically working out what objects (dependencies) an instance of the main Listing 3.25 SETUP Method Rewritten Using Z Statement
190 191
As you can see, when using this approach you dont need DATA statements to INSERT parameter_value_information INTO TABLE mt_parameter_values.
declare the database access object or the logging object. In addition, you only
ENDMETHOD.
have one CREATE statement. This may not seem like much in this simple example,
Listing 3.26 DURING CONSTRUCTION Method
but the advantage increases proportionally with the complexity of the class being
tested.
The next method called as part of the rewritten SETUP method is the INSTEAD_OF
method (Listing 3.27). This method takes in as parameters the subclasses you
Note
want to create instead of a superclass, and that relation is stored in a hashed table.
You can also use this same methodology if the importing parameter of the object con-
structor is an interface. You just pass the interface name in to the INSTEAD_OF method METHOD instead_of.
* Local Variables
rather than the main class name.
DATA: sub_class_to_use_info LIKE LINE OF mt_sub_classes_to_use,
created_objects_info LIKE LINE OF mt_created_objects.
The first method called in Listing 3.25 is the DURING_CONSTRUCTION method. This
sub_class_to_use_info-main_class = using_main_class.
is shown in greater detail in Listing 3.26; it analyzes elementary parameters and sub_class_to_use_info-sub_class = use_sub_class.
then does nothing fancier than adding entries to an internal table.
"Add entry at the start, so it takes priority over previous
METHOD during_construction. "similar entries
* Local Variables INSERT sub_class_to_use_info INTO mt_sub_classes_to_use INDEX 1.
DATA: dummy_string TYPE string ##needed,
data_element_name TYPE string, "A specific object instance can be passed in, sometimes
parameter_value_information LIKE LINE OF mt_parameter_values. "a generated instance created via a framework
CHECK with_specific_instance IS SUPPLIED.
parameter_value_information-identifier = for_parameter. CHECK with_specific_instance IS BOUND.
parameter_value_information-do_value = REF #( use_value ).
created_objects_info-clsname = use_sub_class.
CHECK sy-subrc = 0. created_objects_info-object = with_specific_instance.
INSERT created_objects_info INTO TABLE mt_created_objects.
CALL METHOD cl_abap_structdescr=>describe_by_data_ref
EXPORTING ENDMETHOD.
p_data_ref = parameter_value_information-do_value
Listing 3.27 INSTEAD_OF Method
RECEIVING
p_descr_ref = DATA(type_description)
EXCEPTIONS The last part of the rewritten SETUP method is the CREATE_BY_INJECTION method
reference_is_initial = 1
(Listing 3.28). This is written as close to plain English as possible so that the code
OTHERS = 2.
is more or less self-explanatory. In essence, youre passing the input values you
IF sy-subrc <> 0. just stored into the constructor method when creating your class under test and
RETURN.
any smaller classes it requires.
ENDIF.
METHOD create_via_injection.
SPLIT type_description->absolute_name AT '=' INTO dummy_string data_ * Local Variables
element_name. DATA: class_in_reference_details TYPE REF TO cl_abap_refdescr.
parameter_value_information-rollname = data_element_name. * Determine the class type of the reference object passed in
class_in_reference_details ?=
cl_abap_refdescr=>describe_by_data( co_object ).
192 193
DATA(class_in_type_details) = Error Handling

class_in_reference_details->get_referenced_type( ).
DATA(class_passed_in) = Theres virtually no error handling in the code just discussed (except for throwing fatal
class_in_type_details->get_relative_name( ). exceptions when unexpected things occur). This could be a lot more elegantbut its
the basic principle of automating dependency injection, not elegance, thats our current
"See if we need to create the real class, or a subclass
determine_class_to_create( focus.
EXPORTING
id_class_passed_in = CONV #( class_passed_in )
io_class_in_type_details = class_in_type_details
IMPORTING
3.4.2 Automating Mock Object Creation: Test Double Framework
ed_class_type_to_create = DATA(class_type_to_create) Unit testing frameworks have been around for quite some time in other lan-
eo_class_to_create_type_detail = DATA(class_to_create_type_detail) ).
guages, such as Java and C++. ABAP has joined the club rather late in the day. One
"Buffering causes unforseen results, so optional default "off" advantage of this is that ABAP developers can look at problems other languages
IF mf_use_buffering = abap_true. encounteredand solvedsome years ago, and if they find the same problem,
READ TABLE mt_created_objects INTO DATA(created_objects_info)
WITH TABLE KEY clsname = class_type_to_create.
then they can implement the same sort of solution without having to reinvent the
wheel. Mock objects are a great example of this: Many different mock object
IF sy-subrc = 0. frameworks for Java were born to take a lot of the pain out of the process.
"We already have an instance of this class we can use
co_object ?= created_objects_info-object. It wasnt until ABAP 7.4 that SAP created the ABAP Test Double Framework
RETURN.
ENDIF.
(hereafter ATDF because thats not such a mouthful and because I dont think I
ENDIF."Do we buffer created objects? could get away with calling it the mines a double framework), which is the
equivalent of the mock object framework in all those other languages.
"See if the object we want to create has parameters, and if so, fill th
em up Good OO design recommends that virtually every class has its public signature
fill_constructor_parameters(
EXPORTING io_class_to_create_type_detail =
defined via an interface. This is known in academic circles as the Joe Dolce princi-
class_to_create_type_detail " Class to Create Type Details ple, and the reasons that this is a Good Thing are too many and too complicated
IMPORTING et_signature_values = to go into here, but suffice it to say that this helps you follow the OO principle of
DATA(signature_value_table) ). " Constructor Parameters
favoring composition over inheritance. The ATDF works by using classes for
create_parameter_object( which the public signature is defined via an interface.
EXPORTING id_class_type_to_create = class_type_to_create
it_signature_values = signature_value_table " Parameter Values For any given method, there are several generic behavior types that you would
CHANGING co_object = co_object )." Created Object expect and that youll want to test and thus also want to mock. Earlier in the chap-
ENDMETHOD.Create by Injection
ter you saw some specific examples of these generic behaviors: either the correct
Listing 3.28 CREATE_BY_INJECTION Method result for a given set of input data or a violation of the methods contract with the
calling program. The next two sections cover each case.
If you want to drill into this even more, you can download this code from
www.sap-press.com/4161 and run it in debug mode to see whats happening. Verifying Correct Results
In summary, dependency injection provides a way to set up complicated classes You can use the ATDF to verify correct results, as demonstrated in Listing 3.29. In
while using a lot less code, which will enable you to create test classes with less our example, the class to be mocked is ZCL_MONSTER_SIMULATOR, which imple-
effort. ments interface ZIF_MONSTER_SIMULATOR. Listing 3.29 demonstrates a number of
194 195
concepts; lets examine them one at a time before looking at the listing as a Its fairly obvious what the result is going to be, but the test method ends with
whole. two assertions: one to see if the correct result has been returned and one to see if
the method was called once and only once as expected.
First, you create the mock object instance, which is an instance of a (nonexistent)
class that implements the chosen interface. This dummy class has empty imple- Listing 3.29 combines these various lines of code. When you put them all
mentations for every method defined in the interface, as follows: together, what have you got? A lovely unit test!
mock_monster_simulator ?= cl_abap_testdouble=>create( interface_name ). METHOD mocking_framework_test.

* Local Variables
In our example, the method to be mocked is CALCULATE_SCARINESS. This may DATA: interface_name TYPE seoclsname
seem odd, but the method name is not mentioned at the start of the process of VALUE 'ZIF_MONSTER_SIMULATOR',
setting this up; you just state the result that youre expecting back from this yet- mock_monster_simulator TYPE REF TO zif_monster_simulator,
scariness_description TYPE string.
unnamed method, as follows:
"Create the Test Double Instance
cl_abap_testdouble=>configure_call( mock_monster_simulator )- mock_monster_simulator ?= cl_abap_testdouble=>create( interface_name ).
>returning( 'REALLY SCARY' ).
Now is the time to overcomplicate things and say that, in this unit test, you expect "What result do we expect back from the called method?
cl_abap_testdouble=>configure_call( mock_monster_simulator )-
the method to be called once and once only. The previous line of code is modified >returning( 'REALLY SCARY' )->and_expect( )->is_called_times( 1 ).
as follows:
"Prepare the simulated input details e.g. monster strength
cl_abap_testdouble=>configure_call( mock_monster_simulator )- given_monster_details_entered( ).
>returning( 'REALLY SCARY' )->and_expect( )->is_called_times( 1 ).
"Say what method we are mocking and the input values
The names of the standard methods make the code read almost like English, mock_monster_simulator->calculate_scariness( is_bom_input_data = ms_
which is a Good Thing. input_data ).
Next, you set up the input data. As mentioned earlier in Listing 3.15, we have a "Invoke the production code to be tested
special helper method for this called GIVEN_MONSTER_DETAILS_ENTERED, which fills scariness_description = mock_monster_simulator->calculate_
scariness( ms_input_data ).
in the values for the input structure, because there could be quite a few such val-
ues. Now, you can finally say (1) which method it is you want to mock, and (2) "Was the correct value returned?
what input values should give the result you just specified (i.e., REALLY SCARY), as cl_abap_unit_assert=>assert_equals(
exp = 'REALLY SCARY'
follows: act = scariness_description
msg = 'Monster is not scary enough' ).
mock_monster_simulator->calculate_scariness( is_bom_input_data = ms_
input_data ).
"Listen very carefully - was the method only called once?
From now on, calls to methods of our mock instance will be indistinguishable cl_abap_testdouble=>verify_expectations( mock_monster_simulator ).
from calls to an instance of an actual class. To prove this, perform a real call to the ENDMETHOD."Mocking Framework Test
same method (that may seem pointless now, but just you wait and see) to fill a Listing 3.29 Coding Unit Test without Needing Definitions and Implementations
variable with the scariness description, as follows:
scariness_description = mock_monster_simulator->calculate_ As you can see, the ATDF does away with the need to create definitions and
scariness( ms_input_data ). implementations of the class you want to mock. You only need to focus on what
output values should be returned for what input values for what class. This
196 197
methodology uses ABAPs ability to generate temporary programs that live only "What result do we expect back from the called method?
DATA(lo_violation) = NEW zcx_violated_precondition_stat( ).
in memory and only exist as long as the mother program is running. In effect,
cl_abap_testdouble=>configure_call( mock_monster_simulator )->raise_
the framework writes the method definitions and implementations for you at exception( lo_violation ).
runtime.
Note also that during the test a check is performed to see if the CALCULATE_ CLEAR ms_input_data.
SCARINESS method was in fact called in the preceding code. Even if a mock
method doesnt do anything at all in a test situation, you still want to be sure that TRY.
its been called. mock_monster_simulator->calculate_scariness( is_bom_input_data = ms_
input_data ).
Method Chaining
"Invoke the production code to be tested
Listing 3.29 also uses method chaining, a feature we discussed in Chapter 2. Four meth- scariness_description = mock_monster_simulator->calculate_
scariness( ms_input_data ).
ods in a row are called on CL_ABAP_TESTDOUBLE: CONFIGURE_CALL, RETURNING, AND_
EXPECT, and IS_CALLED_TIMES. Before release 7.02 of ABAP, you would have had to
CATCH zcx_violated_precondition_stat.
use four lines here, create a helper variable on the first line, and use that variable on "All is well, we wanted the exception to be raised
each subsequent line. RETURN.
ENDTRY.
"Was the correct value returned?

Verifying Contract Violations cl_abap_unit_assert=>fail(
msg = 'Expected Exception was not Raised' ).
Sometimes you want to simulate the exception thats raised when a program
encounters nonsense data, for example: if the input data being passed in by the ENDMETHOD."Mocking Exception Test
calling program breaks the contract with the method being called. Listing 3.30 Mocking Exception Using ATDF
In the running example used in this chapter, the CALCULATE_SCARINESS method

Note that in order to mock an exception being raised, the exception being tested
has a contract with the calling program such that if the input data structure is
for has to be declared in the signature of the method being mocked. Exception
totally blank, then there is no way the scariness can be calculated. This means that
classes inheriting from CX_NO_CHECK cant be mentioned in a method signature
the calling program is at fault and an exception should be raised. You want to per-
and thus cant be simulated.
form a test to make sure that in such a situation an exception actually is raised.
See the Recommended Reading box at the end of the chapter for a link to the offi-
Do so by substituting the RETURNING method in CONFIGURE_CALL with RAISE_
cial blog detailing all the features of ATDF. There are more than I can go into here;
EXCEPTION, as shown in Listing 3.30.
whats more, new features are going to be added with each new release, which is
METHOD mocking_exception_test. wonderful news.
* Local Variables
DATA: interface_name TYPE seoclsname
VALUE 'ZIF_MONSTER_SIMULATOR', Alternatives to ATDF
mock_monster_simulator TYPE REF TO zif_monster_simulator,
Without this framework, the way to proceed is to create mock classes that are sub-
scariness_description TYPE string.
classes of the real class (e.g., ZCL_MOCK_DATABASE_LAYER), redefine some methods, and
"Create the Test Double Instance put some hard-coded logic inside the redefined method to return certain values based
mock_monster_simulator ?= cl_abap_testdouble=>create( interface_name ). upon input values. You could also create a mock class that implements an interface
198 199
mock_monster_simulator->calculate_scariness( is_bom_input_data = ms_

but sometimes this is even more work, because in earlier versions of ABAP you need an input_data ).
implementation for every method in the interface.
* Now pass this mocked up simulator object into a class that
* expects a real object as an input.
DATA(laboratory) = NEW zcl_monster_laboratory( ).
3.4.3 Combining Dependency Injection and the ABAP Test
Double Framework DATA(is_the_monster_ok) = laboratory->evaluate_monster(
is_bom_input_data = ms_input_data
Its quite possible that you didnt think the examples in the last section were the io_simulator = mock_monster_simulator ).
greatest thing since sliced bread, because of course the tests were going to pass; it
cl_abap_unit_assert=>assert_equals(
was like adding up one and one and expecting two. The real value of ATDF comes
exp = abap_true
to light when you pass your generated mock object into a larger class being act = is_the_monster_ok
tested. To demonstrate this, create a ZCL_MONSTER_LABORATORY class that takes the msg = 'Monster is just not good enough' ).
SIMULATOR object as input and then uses a complex set of business logic to say
ENDMETHOD."Laboratory Test
whether the monster is any good. That business logic is what we want to test. Listing 3.31 Passing In Mocked-Up Interface to Real Class
To be more precise, the EVALUATE_MONSTER method of the LABORATORY object will

call the CALCULATE_SCARINESS method of the monster simulator instance, which In Listing 3.31, large chunks of code that you would normally need have been
was passed into it at some point during processing. At that point, you want the removed; you didnt need to code either a definition or an implementation for
mocked up result to be returned to the CALCULATE_SCARINESS method, as opposed the mock monster simulator class. Nonetheless, the end result is just as good as if
to what the normal method would return in production. youd gone down the longer route. The laboratory object neither knows nor cares
that whats been passed into it is not a real instance of a class, but instead a gen-
The code in which the ZCL_MONSTER_LABORATORY class imports the SIMULATOR erated mock object.
object during one of its methods is shown in Listing 3.31. The first part of the
code is the same as in Listing 3.29 but with the mocked up simulator instance Take this one step further: Pretend the monster simulator needs a whole raft of
injected into the laboratory object. objects that are a pain to set up (e.g., a complicated laboratory object needs a
monster creator object in its constructor, and a monster creator object needs a
METHOD laboratory_test.
* Local Variables
specialty in its constructor), so you combine ATDF with the dependency injection
DATA: interface_name TYPE seoclsname framework. In the injection framework class thats part of Listing 3.31, the
VALUE 'ZIF_MONSTER_SIMULATOR', method FOR_THE has a parameter through which you can pass in the generated
mock_monster_simulator TYPE REF TO zif_monster_simulator.
object. You need this so that you can enable your ATDF-generated instance to be
"Create the Test Double Instance used when creating the class under test using injection. This is shown in Listing
mock_monster_simulator ?= cl_abap_testdouble=>create( interface_name ). 3.32.
"What result do we expect back from the called method? Same set up code as before . Then .
cl_abap_testdouble=>configure_call( mock_monster_simulator )- * Create the complicated receiving object via injection
>returning( 'REALLY SCARY' )->and_expect( )->is_called_times( 1 ). DATA: laboratory TYPE REF TO zcl_complicated_laboratory,
speciality TYPE zde_monster_type VALUE 'SCARY'.
given_monster_details_entered( ). "In unit tests, everything has to start in pristine condition
zcl_bc_injector=>reset( ).
200 201
"A Monster Creator (e.g., the baron ) needs a speciality method, hard-coded data was used. The rest of the book goes on and on about
zcl_bc_injector=>during_construction( :
how hard-coded values are the work of the devil, so theres some disparity here
for_parameter = 'ID_SPECIALITY' use_value = speciality ).
a circle that needs to be squared.
"A complicated laboratory needs a Monster Creator object but this will
be created automatically by the injector In most cases, you want to test your method with a wide variety of possible
inputs to make sure the correct result is returned in every case. One way to do
"Pass in the instance of the simulator we have mocked up
this is to code one unit test with one set of inputs to ensure it comes back with the
zcl_bc_injector=>for_the(
interface_or_class = monster_simulator_interface correct result, and then move the transport into test (or production) and wait for
use_specific_instance = mock_monster_simulator ). people to tell you everything falls apart when you input a different set of results.
(Hopefully, you can see that might not be the ideal way to go about things.) It
"During injection the mocked up object gets passed in with
"all the other data we have set up would be so much better if you started off with a wide range of scenarios, ran
zcl_bc_injector=>create_via_injection( tests for all of them, made sure they all worked, and then moved the program to
CHANGING co_object = laboratory ).
test. Everyone would be a lot happierespecially you.
DATA(is_the_monster_ok) = laboratory->evaluate_monster( ms_input_
Getting a list of scenarios was easy: I went to the business users (Igor and his
data ).
hunchback mates) and asked for a list of a hundred sets of monster requirements
cl_abap_unit_assert=>assert_equals( and their monster BOMs. Before I could say Jack Robinson, I had a spreadsheet
exp = abap_true
in my hot little hands. Wonderful! Now, should I manually code one hundred dif-
act = is_the_monster_ok
msg = 'Monster is just not good enough' ). ferent test methods, each with the same method call with a different set of inputs
Listing 3.32 Combining ATDF with Dependency Injection followed by assertions with a different set of results? Doesnt sound like much
fun.
In Listing 3.32, youre passing in a generated object that will be used when the
You could create a database table (but you might have to create different ones for
injection class creates the class under test.
different programs) or store the test data in the standard ECATT automated tests
What the examples that culminate in Listing 3.32 show is that its possible to script system. My favorite solution to this problem, however, is an open-source
simplify the SETUP method dramatically when creating the class under test. You project created by a programmer called Alexander Tsybulsky and his colleagues,
can use ATDF to set up test doubles with a lot less effort and use injection to who came up with a framework called the Mockup Loader, which lives on the
avoid having to code long strings of CREATE OBJECT statements that pass the GitHub site and can be downloaded to your system via the link found in the Rec-
results into each other before handing the end result into the class under test ommended Reading box at the end of this chapter.
when its finally created. The two frameworks werent created with the intention
of working together, but by a happy accident they fit together like the pieces of ABAP Open-Source Projects
a jigsaw puzzle. Several times throughout this book, well refer to open-source ABAP projects, which
started life in the SAP Code Exchange section of the SAP Community Network website
but nowadays live on sites like GitHub. The obvious benefit is that these are free. Some
3.4.4 Unit Tests with Massive Amounts of Data development departments have rules against installing such things, but I feel theyre
In the United Kingdom, children can buy I-Spy books, in which they have to spot just cutting off their nose to spite their face.
various things. Once theyve spotted them all, they send the completed list to Big The important point to note is that these are not finished products, so installing them is
not like installing the sort of SAP add-on you pay for. Its highly likely youll encounter
Chief I-Spy, who sends them a feather in return. If you were on the lookout for a
bugs and that the tool wont do 100% of what you want it to do. In both cases, I
feather, you have may have spied that in all the preceding examples, regardless of
202 203
Then, create an instance of your mockup loader. If you spelled the name of the
strongly encourage you to fix the bug or add the new feature, and then update the
open-source project so that the whole SAP community benefits.
MIME object incorrectly, this is where youll find out in a hurry, due to a fatal
error message. Next, load the MIME object into an internal table based on the
The very first open-source project youll need to install is SAPlink so that you can down-
load any others you need easily. You can get SAPlink from www.saplink.org. structure you declared earlier. At this point, if the columns in the structure dont
match the columns in the spreadsheet, an exception is raised and the test fails.
This is good: Making sure the test data format is correct is just another step in get-
Before you begin, you should have the test data loaded inside the SAP develop-
ting the unit tests to pass.
ment system (where the tests will run, of course). Thats much better than having
the test data on some sort of shared directory or, worse, on a developers laptop. The rest is plain sailing: Loop through the test cases, call the method being tested
each time with the specific test case input data, and see if the result matches the
The GitHub page for the Mockup Loader gives detailed instructions for storing a
specific test case result data. As mentioned earlier, you can use the QUIT parame-
spreadsheet inside the MIME repository, which allows you to store various files
ter to determine if you want to see all the results at once or stop at the first failure;
(like spreadsheets) inside SAP. You can upload as many spreadsheets as you want:
the code in Listing 3.33 stops at the first failure.
one for input data, one for output data, or both in one sheet, as in the following
example. Even betterif you have different types of data, you can store each one METHOD mockup_loader.
as a sheet inside the one big worksheet, keeping everything in the same place. * Local Variables
TYPES: BEGIN OF l_typ_monster_test_data,
Once the test data in the spreadsheet is uploaded into SAP, the fun begins. Listing strength TYPE zde_monster_strength,
brain_size TYPE zde_monster_brain_size,
3.33 demonstrates a test method that evaluates lots of test cases at once, without sanity TYPE zde_monster_sanity,
any of the fancy things mentioned elsewhere in the chapter so as not to distract ssatn TYPE zde_component_type_percentage,
from whats being demonstrated. sspdt TYPE zde_component_type_percentage,
END OF l_typ_monster_test_data.
In this example, the idea is to loop through different sets of customer require-
* Need to specify the type of the table, to make sure
ments to make sure the correct component split is returned. For now, you can * correct tests are done on the data loaded from MIME
ignore SSATN and SSPDT and the percentage split; those elements will be DATA test_cases_table TYPE TABLE OF l_typ_monster_test_data.
detailed in Chapter 8.
"Name of Entry in SMW0
Start with a spreadsheet with five columns; the first three are customer require- zcl_mockup_loader=>class_set_source(
i_type = 'MIME'
ments (e.g., what the customer desires in a monster) and the last two are result i_path = 'ZMONSTER_TEST_DATA' ).
columns (percentages of SSATN and SSPDT, respectively). At the start of the test
method, declare a structure that exactly matches the columns in the spreadsheet; TRY.
DATA(mockup_loader) = zcl_mockup_loader=>get_instance( ).
the spreadsheet has to have a header row that exactly matches the names of the CATCH zcx_mockup_loader_error INTO DATA(loader_exception).
fields in this structure. cl_abap_unit_assert=>fail( loader_exception->get_text( ) ).
ENDTRY.
When you upload your spreadsheet to the MIME repository using Transaction
SMW0, you give the file a name. In the test method, you must also specify the fact TRY.
"Load test cases. The format is SPREADSHEET NAME/Sheet Name
that this is a MIME object and the name of that object. You could specify FILE and mockup_loader->load_data(
a directory path, but that would be uncool; youd never be invited to parties EXPORTING i_obj = 'MONSTER_TEST_DATA/monster_tests'
again. IMPORTING e_container = test_cases_table ).
204 205
3 ABAP Unit and Test-Driven Development Summary 3.5
CATCH zcx_mockup_loader_error INTO loader_exception. 3.5 Summary

cl_abap_unit_assert=>fail( loader_exception->get_text( ) ).
ENDTRY.
Mountain climbers will tell you that their pastime is not easy, but its all worth it
LOOP AT test_cases_table INTO DATA(test_case). once youve achieved the incredibly difficult task of climbing the mountain and
mo_class_under_test->get_component_split( are standing on the summit, on top of the world, able to see for miles. It may not
EXPORTING
id_strength = test_case-strength
seem similar on the surface, but unit testing is like that. Its not easy at allquite
id_brain_size = test_case-brain_size the reversebut once youve enabled your existing programs with full test cov-
id_sanity = test_case-sanity erage and you create all new programs using this methodology, then you too sud-
IMPORTING
id_ssatn = DATA(actual_percentage_ssatn) denly have a much-improved view.
id_sspdt = DATA(actual_percentage_sspdt) ).
Quite simply, you can make any changes you want toradical changesintro-
cl_abap_unit_assert=>assert_equals( duce new technology, totally refactor (redesign) the innards of the program, any-
exp = test_case-ssatn thing at all, and after you change even one line of code you can follow the menu
act = actual_percentage_ssatn
msg = |{ test_case-strength } + { test_case-brain_ path Test Unit Test and know within seconds if youve broken any existing
size } + { test_case-sanity } gets incorrect SSATN %age| ). functions. This is not to be sneezed at. It is in fact the Holy Grail of programming.
cl_abap_unit_assert=>assert_equals( One question that hasnt come up yet is this: What if someone else comes along
exp = test_case-sspdt and changes your program by adding a new feature, but accidently breaks some-
act = actual_percentage_sspdt
msg = |{ test_case-strength } + { test_case-brain_ thing else and doesnt bother to run the unit tests, and thus doesnt realize that
size } + { test_case-sanity } gets incorrect SSPDT %age| ). hes broken something? Clearly, you somehow need to embed the automated
unit tests into the whole change control procedure. Conveniently, this leads
ENDLOOP."Test Cases
nicely to the subject of the next chapter: ABAP Test Cockpit.
ENDMETHOD."Mockup Loader
Listing 3.33 Test Method to Load Multiple Test Cases Recommended Reading
Head First Design Patterns

Every so often, a new problem will arise in production; youll just add a new line Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra, OReilly Media, 2004
to your spreadsheet, upload the changed version, and then fix the newly added Behavior-Driven Development
(broken) test. http://dannorth.net/introducing-bdd (Dan North)
The Art of Unit Testing
This approach can be combined with everything else mentioned in this section.
http://artofunittesting.com (Roy Osherove)
For a nice (complicated) example, you could set up a bunch of mock objects with
The Pragmatic Programmer
fake expected behavior, pass them into the class under test using dependency https://en.wikipedia.org/wiki/The_Pragmatic_Programmer (Andrew Hunt and David
injection, and then run a bucket load of test cases using the mockup loaded. As Thomas, The Pragmatic Bookshelf, 1999)
Snoopy would say, You see how it all comes together? Dependency Injection
http://scn.sap.com/community/abap/blog/2013/08/28/dependency-injection-for-
abap (Jack Stewart)
mockA
http://uwekunath.wordpress.com/2013/10/16/mocka-released-a-new-abap-mock-
ing-framework (Uwe Kunath)
206 207
3 ABAP Unit and Test-Driven Development
ABAP Test Double Framework

http://scn.sap.com/docs/DOC-61154 (Parjul Meyana)
Mockup Loader
http://scn.sap.com/community/abap/blog/2015/11/12/unit-testing-mockup-loader-
for-abap (Alexander Tsybulsky)
208
Contents
Foreword ......................................................................................................... 19
Acknowledgments ............................................................................................ 21
Introduction ..................................................................................................... 23
1 ABAP in Eclipse ......................................................................... 33
1.1 Installation .................................................................................... 35

1.1.1 Installing Eclipse ............................................................... 36
1.1.2 Installing SAP-Specific Add-Ons ....................................... 38
1.1.3 Connecting Eclipse to a Backend SAP System ................... 40
1.2 Features ........................................................................................ 41
1.2.1 Working on Multiple Objects at the Same Time ............... 45
1.2.2 Bookmarking .................................................................... 47
1.2.3 Creating a Method from the Calling Code ........................ 49
1.2.4 Extracting a Method ......................................................... 54
1.2.5 Deleting Unused Variables ............................................... 58
1.2.6 Creating Instance Attributes and Method Parameters ....... 59
1.2.7 Creating Class Constructors .............................................. 60
1.2.8 Creating Structures ........................................................... 61
1.2.9 Creating Data Elements .................................................... 63
1.2.10 Handling an Exception ..................................................... 63
1.2.11 Changing Package Assignment ......................................... 65
1.2.12 Getting New IDE Features Automatically .......................... 65
1.3 Testing and Troubleshooting ......................................................... 69
1.3.1 Unit Testing Code Coverage ............................................. 69
1.3.2 Debugging ....................................................................... 72
1.3.3 Runtime Analysis .............................................................. 75
1.3.4 Dynamic Log Points ......................................................... 77
1.4 Customization Options with User-Defined Plug-Ins ....................... 79
1.4.1 UMAP .............................................................................. 81
1.4.2 Obeo ............................................................................... 87
1.5 Summary ....................................................................................... 87
2 New Language Features in ABAP 7.4 and 7.5 ........................... 89
2.1 Database Access ............................................................................ 90

2.1.1 New Commands in OpenSQL ........................................... 90
9
Contents Contents
2.1.2 Creating While Reading .................................................... 95 2.6.9 Grouping Internal Tables .................................................. 140
2.1.3 Buffering Improvements ................................................... 96 2.6.10 Extracting One Table from Another .................................. 143
2.1.4 Inner Join Improvements .................................................. 98 2.7 Object-Oriented Programming ...................................................... 145
2.1.5 UNION ............................................................................ 100 2.7.1 Upcasting/Downcasting with CAST ................................... 146
2.1.6 Code Completion in SELECT Statements ........................... 101 2.7.2 Finding the Subclass of an Object Instance ....................... 147
2.1.7 Filling a Database Table with Summarized Data ................ 101 2.7.3 CHANGING and EXPORTING Parameters ......................... 148
2.2 Declaring and Creating Variables ................................................... 102 2.7.4 Changes to Interfaces ....................................................... 149
2.2.1 Omitting the Declaration of TYPE POOL Statements ........ 103 2.8 Search Helps .................................................................................. 151
2.2.2 Omitting Data Type Declarations ...................................... 104 2.8.1 Predictive Search Helps .................................................... 151
2.2.3 Creating Objects Using NEW ............................................ 105 2.8.2 Search Help in SE80 ......................................................... 152
2.2.4 Filling Structures and Internal Tables While Creating 2.9 Unit Testing ................................................................................... 153
Them Using VALUE .......................................................... 106 2.9.1 Creating Test Doubles Relating to Interfaces ..................... 153
2.2.5 Filling Internal Tables from Other Tables Using FOR ......... 107 2.9.2 Coding Return Values from Test Doubles ......................... 154
2.2.6 Creating Short-Lived Variables Using LET ......................... 108 2.9.3 Creating Test Doubles Related to Complex Objects .......... 155
2.3 String Processing ........................................................................... 109 2.10 Summary ....................................................................................... 156
2.3.1 New String Features in Release 7.02 ................................. 109
2.3.2 New String Features in Release 7.4 ................................... 110 3 ABAP Unit and Test-Driven Development ................................ 159
2.4 Calling Functions ........................................................................... 111
2.4.1 Method Chaining ............................................................. 111 3.1 Eliminating Dependencies ............................................................. 161
2.4.2 Avoiding Type Mismatch Dumps When Calling 3.1.1 Identifying Dependencies ................................................. 162
Functions ......................................................................... 112 3.1.2 Breaking Up Dependencies Using Test Seams ................... 164
2.4.3 Using Constructor Operators to Convert Strings ............... 114 3.1.3 Breaking Up Dependencies Properly ................................. 166
2.4.4 Functions That Expect TYPE REF TO DATA ....................... 115 3.2 Implementing Mock Objects ......................................................... 168
2.5 Conditional Logic .......................................................................... 116 3.2.1 Test Injection for Test Seams ............................................ 168
2.5.1 Using Functional Methods in Logical Expressions ............. 116 3.2.2 Creating Mock Objects ..................................................... 169
2.5.2 Omitting ABAP_TRUE ...................................................... 117 3.2.3 Proper Injection ............................................................... 171
2.5.3 Using XSDBOOL as a Workaround for BOOLC .................. 119 3.3 Writing and Implementing Unit Tests ............................................ 173
2.5.4 The SWITCH Statement as a Replacement for CASE .......... 120 3.3.1 Defining Test Classes ........................................................ 173
2.5.5 The COND Statement as a Replacement for IF/ELSE ......... 122 3.3.2 Implementing Test Classes ............................................... 180
2.6 Internal Tables ............................................................................... 124 3.4 Automating the Test Process ......................................................... 189
2.6.1 Using Secondary Keys to Access the Same Internal Table 3.4.1 Automating Dependency Injection ................................... 190
in Different Ways ............................................................. 124 3.4.2 Automating Mock Object Creation: Test Double
2.6.2 Table Work Areas ............................................................. 127 Framework ....................................................................... 195
2.6.3 Reading from a Table ....................................................... 128 3.4.3 Combining Dependency Injection and the ABAP
2.6.4 CORRESPONDING for Normal Internal Tables .................. 130 Test Double Framework ................................................... 200
2.6.5 MOVE-CORRESPONDING for Internal Tables with 3.4.4 Unit Tests with Massive Amounts of Data ........................ 202
Deep Structures ............................................................... 131 3.5 Summary ....................................................................................... 207
2.6.6 Dynamic MOVE-CORRESPONDING ................................. 135
2.6.7 New Functions for Common Internal Table Tasks ............. 137
2.6.8 Internal Table Queries with REDUCE ................................ 139
10 11
Contents Contents
5.4.4 Calling an AMDP from inside a CDS View ........................ 285

4 Custom Code and ABAP Test Cockpit ....................................... 209 5.5 Locating and Pushing Down Code ................................................. 288
5.5.1 Finding Custom Code that Needs to Be Pushed Down ..... 289
4.1 Automatic Run of Unit Tests .......................................................... 211
5.5.2 Which Technique to Use to Push Code Down .................. 291
4.2 Mass Checks .................................................................................. 213
5.5.3 Example ........................................................................... 292
4.2.1 Setting Up Mass Checks ................................................... 214
5.6 SAP HANA-Specific Changes for ABAP .......................................... 298
4.2.2 Running Mass Checks ....................................................... 216
5.6.1 Database Table Design ..................................................... 299
4.2.3 Reviewing Mass Checks .................................................... 220
5.6.2 Avoiding Database-Specific Features ................................ 303
4.2.4 Dismissing False Errors ..................................................... 223
5.6.3 Changes to Database SELECT Coding ................................ 304
4.3 Recent Code Inspector Enhancements ........................................... 227
5.7 Summary ....................................................................................... 308
4.3.1 Unsecure FOR ALL ENTRIES (12/5/2) ............................... 228
4.3.2 SELECT * Analysis (14/9/2) ............................................... 230
4.3.3 Improving FOR ALL ENTRIES (14/9/2) .............................. 232 6 Exception Classes and Design by Contract ............................... 311
4.3.4 SELECT with DELETE (14/9/2) .......................................... 233
4.3.5 Check on Statements Following a SELECT without 6.1 Types of Exception Classes ............................................................. 313
ORDER BY (14/9/3) ......................................................... 234 6.1.1 Static Check (Local or Nearby Handling) ........................... 314
4.3.6 SELECTs in Loops across Different Routines (14/9/3) ........ 236 6.1.2 Dynamic Check (Local or Nearby Handling) ...................... 316
4.3.7 Syntax Check on Enhanced Programs (17/10/4) ................ 237 6.1.3 No Check (Remote Handling) ........................................... 316
4.3.8 SORT Statements inside Loops (18/11/5) ......................... 239 6.1.4 Deciding Which Type of Exception Class to Use ............... 318
4.3.9 Copy Current Table Row for LOOP AT (18/11/5) .............. 241 6.2 Designing Exception Classes .......................................................... 319
4.3.10 Nested Sequential Accesses to Internal Tables (7.5) .......... 243 6.2.1 Creating the Exception ..................................................... 320
4.3.11 Test Suspect Conversions (7.5) ......................................... 245 6.2.2 Declaring the Exception ................................................... 322
4.3.12 Technology-Specific Checks (7.02 to 7.5) ......................... 246 6.2.3 Raising the Exception ....................................................... 323
4.4 Custom Code Analyzer: Simplification Database ............................ 248 6.2.4 Cleaning Up after the Exception Is Raised ......................... 326
4.4.1 Preparation ...................................................................... 248 6.2.5 Error Handling with RETRY and RESUME ......................... 328
4.4.2 Usage ............................................................................... 249 6.3 Design by Contract ........................................................................ 332
4.4.3 Aftermath ......................................................................... 251 6.3.1 Preconditions and Postconditions ..................................... 334
4.5 Summary ....................................................................................... 252 6.3.2 Class Invariants ................................................................. 336
6.4 Summary ....................................................................................... 338
5 ABAP Programming Model for SAP HANA ............................... 253

7 Business Object Processing Framework ................................... 341
5.1 The Three Faces of Code Pushdown ............................................... 254
5.2 OpenSQL ....................................................................................... 256 7.1 Manually Defining a Business Object ............................................. 342
5.3 CDS Views ..................................................................................... 256 7.1.1 Creating the Object .......................................................... 343
5.3.1 Creating a CDS View in Eclipse ......................................... 258 7.1.2 Creating a Header Node ................................................... 345
5.3.2 Coding a CDS View in Eclipse ........................................... 261 7.1.3 Creating an Item Node ..................................................... 347
5.3.3 Adding Authority Checks to a CDS View .......................... 274 7.2 Generating a Business Object from a CDS View ............................. 349
5.3.4 Reading a CDS View from an ABAP Program .................... 276 7.3 Using BOPF to Write a DYNPRO-Style Program ............................. 352
5.4 ABAP Managed Database Procedures ............................................ 279 7.3.1 Creating Model Classes .................................................... 353
5.4.1 Defining an AMDP in Eclipse ............................................ 279 7.3.2 Creating or Changing Objects ........................................... 357
5.4.2 Implementing an ADMP in Eclipse ................................... 280 7.3.3 Locking Objects ............................................................... 369
5.4.3 Calling an AMDP from an ABAP Program ......................... 285 7.3.4 Performing Authority Checks ............................................ 370
12 13
Contents Contents
7.3.5 Setting Display Text Using Determinations ....................... 371 9.2.3 Report Flow Step 3: Making Application-Specific
7.3.6 Disabling Certain Commands Using Validations ................ 384 Changes (Specific) ............................................................ 494
7.3.7 Checking Data Integrity Using Validations ........................ 386 9.2.4 Report Flow Step 4: Displaying the Report (Generic) ........ 507
7.3.8 Responding to User Input via Actions ............................... 392 9.3 Adding Custom Command Icons with Programming ...................... 512
7.3.9 Saving to the Database ..................................................... 404 9.3.1 Creating a Method to Automatically Create a Container ... 514
7.3.10 Tracking Changes in BOPF Objects ................................... 411 9.3.2 Changing ZCL_BC_VIEW_SALV_TABLE to Fill the
7.4 Custom Enhancements .................................................................. 420 Container ......................................................................... 514
7.4.1 Enhancing Standard SAP Objects ...................................... 420 9.3.3 Changing the INITIALIZE Method .................................... 516
7.4.2 Using a Custom Interface (Wrapper) ................................. 423 9.3.4 Adding the Custom Commands to the Toolbar ................. 517
7.5 Summary ....................................................................................... 425 9.3.5 Sending User Commands from the Calling Program .......... 518
9.4 Editing Data .................................................................................. 519
8 BRFplus ..................................................................................... 427 9.4.1 Creating a Custom Class to Hold the Standard SALV
Model Class ..................................................................... 520
8.1 The Historic Location of Rules ....................................................... 430 9.4.2 Changing the Initialization Method of
8.1.1 Rules in Peoples Heads .................................................... 430 ZCL_BC_VIEW_SALV_TABLE ............................................ 521
8.1.2 Rules in Customizing Tables ............................................. 432 9.4.3 Adding a Method to Retrieve the Underlying
8.1.3 Rules in ABAP .................................................................. 434 Grid Object ...................................................................... 525
8.2 Creating Rules in BRFplus: Basic Example ...................................... 435 9.4.4 Changing the Calling Program .......................................... 527
8.2.1 Creating a BRFplus Application ......................................... 435 9.4.5 Coding User Command Handling ...................................... 528
8.2.2 Adding Rule Logic ............................................................ 444 9.5 Handling Large Internal Tables with CL_SALV_GUI_TABLE_IDA ..... 531
8.2.3 BRFplus Rules in ABAP ..................................................... 456 9.6 Open-Source Fast ALV Grid Object ................................................ 534
8.3 Creating Rules in BRFplus: Complicated Example ........................... 458 9.7 Summary ....................................................................................... 535
8.4 Simulations .................................................................................... 465
8.5 SAP Business Workflow Integration ............................................... 467 10 ABAP2XLSX and Beyond ........................................................... 537
8.6 Options for Enhancements ............................................................ 472
8.6.1 Procedure Expressions ...................................................... 472 10.1 The Basics ...................................................................................... 539
8.6.2 Application Exits .............................................................. 473 10.1.1 How XLSX Files Are Stored ............................................... 539
8.6.3 Custom Frontends ............................................................ 473 10.1.2 Downloading ABAP2XLSX ................................................ 541
8.6.4 Custom Extensions ........................................................... 474 10.1.3 Creating XLSX Files Using ABAP ....................................... 541
8.7 SAP HANA Rules Framework ......................................................... 474 10.2 Enhancing Custom Reports with ABAP2XLSX ................................ 546
8.8 Summary ....................................................................................... 475 10.2.1 Converting an ALV Object to an Excel Object ................... 546
10.2.2 Changing Number and Text Formats ................................ 548
9 ALV SALV Reporting Framework .............................................. 477 10.2.3 Establishing Printer Settings ............................................. 551
10.2.4 Using Conditional Formatting ........................................... 554
9.1 Getting Started .............................................................................. 480 10.2.5 Creating Spreadsheets with Multiple Worksheets ............. 563
9.1.1 Defining a SALV-Specific (Concrete) Class ......................... 481 10.2.6 Using Graphs and Pie Charts ............................................. 565
9.1.2 Coding a Program to Call a Report ................................... 482 10.2.7 Embedding Macros .......................................................... 568
9.2 Designing a Report Interface ......................................................... 484 10.2.8 Emailing the Result .......................................................... 574
9.2.1 Report Flow Step 1: Creating a Container 10.2.9 Adding Hyperlinks to SAP Transactions ............................ 577
(Generic/Optional) ........................................................... 486 10.3 Tips and Tricks ............................................................................... 582
9.2.2 Report Flow Step 2: Initializing a Report (Generic) ........... 487 10.3.1 Using the Enhancement Framework for Your Own Fixes ... 583
14 15
Contents Contents
10.3.2 Creating a Reusable Custom Framework ........................... 585 12.4 Backend Tasks: Automatically Generating the Model ..................... 691
10.4 Beyond Spreadsheets: Microsoft Word Documents ........................ 586 12.4.1 BOPF/SAP Gateway Integration ........................................ 691
10.4.1 Installing the Tool ............................................................ 587 12.4.2 CDS View/SAP Gateway Integration ................................. 694
10.4.2 Creating a Template ......................................................... 588 12.5 Frontend Tasks: Creating the View and Controller Using SAPUI5 ... 699
10.4.3 Filling the Template ......................................................... 589 12.5.1 First Steps ........................................................................ 699
10.5 Summary ....................................................................................... 596 12.5.2 View ................................................................................ 702
12.5.3 Controller ......................................................................... 715
11 Web Dynpro ABAP and Floorplan Manager ............................. 599 12.5.4 Testing Your Application .................................................. 721
12.6 Generating SAPUI5 Applications from SAP Web IDE Templates ..... 723
11.1 The Model-View-Controller Concept ............................................. 600 12.7 Generating SAPUI5 Applications from the BUILD Tool ................... 728
11.1.1 Model .............................................................................. 601 12.8 Adding Elements with OpenUI5 .................................................... 737
11.1.2 View ................................................................................ 603 12.9 Importing SAPUI5 Applications to SAP ERP ................................... 741
11.1.3 Controller ......................................................................... 606 12.9.1 Storing the Application in Releases Lower Than 7.31 ....... 742
11.2 Building the WDA Application ....................................................... 607 12.9.2 Storing the Application in Releases 7.31 and Above ......... 744
11.2.1 Creating a Web Dynpro Component ................................. 609 12.9.3 Testing the SAPUI5 Application from within SAP ERP ...... 745
11.2.2 Declaring Data Structures for the Controller ..................... 611 12.10 SAPUI5 vs. SAP Fiori ...................................................................... 747
11.2.3 Establishing View Settings ................................................ 613 12.11 Summary ....................................................................................... 748
11.2.4 Defining the Windows ..................................................... 623
11.2.5 Navigating between Views inside the Window ................. 624 13 ABAP Channels .......................................................................... 751
11.2.6 Enabling the Application to be Called ............................... 627
11.3 Coding the WDA Application ........................................................ 628 13.1 General Concept ............................................................................ 752
11.3.1 Linking the Controller to the Model ................................. 629 13.1.1 ABAP Messaging Channels ............................................... 753
11.3.2 Selecting Monster Records ............................................... 629 13.1.2 ABAP Push Channels ........................................................ 754
11.3.3 Navigating to the Single-Record View .............................. 635 13.2 ABAP Messaging Channels: SAP GUI Example ............................... 755
11.4 Using Floorplan Manager to Create WDA Applications .................. 639 13.2.1 Coding the Sending Application ....................................... 758
11.4.1 Creating an Application Using Floorplan Manager ............ 640 13.2.2 Coding the Receiving Application ..................................... 764
11.4.2 Integrating BOPF with Floorplan Manager ........................ 651 13.2.3 Watching the Applications Communicate ......................... 768
11.5 Summary ....................................................................................... 656 13.3 ABAP Push Channels: SAPUI5 Example .......................................... 771
13.3.1 Coding the Receiving (Backend) Components ................... 772
12 SAPUI5 ...................................................................................... 659 13.3.2 Coding the Sending (Frontend) Application ...................... 780
13.4 Internet of Things Relevance ......................................................... 782
12.1 Architecture .................................................................................. 661 13.5 Summary ....................................................................................... 783
12.1.1 Frontend: What SAPUI5 Is ............................................... 662
12.1.2 Backend: What SAP Gateway Is ........................................ 663 Appendices ....................................................................................... 785
12.2 Prerequisites .................................................................................. 664
12.2.1 Requirements in SAP ........................................................ 664 A Conclusion ............................................................................................... 785
12.2.2 Requirements on Your Local Machine .............................. 665 B The Author .............................................................................................. 789
12.3 Backend Tasks: Creating the Model Manually Using
SAP Gateway ................................................................................. 665 Index ............................................................................................................... 791
12.3.1 Configuration ................................................................... 666
12.3.2 Coding ............................................................................. 680
16 17
Index
A ABAP2XLSX, 537
conditional formatting, 554
ABAP download, 541
constructs, 47 email, 574
development system, 45 enhancement framework, 583
event mechanism, 509 enhancing custom reports, 546
Quick Assist, 53 example programs, 545
ABAP 7.02, 103, 109, 111, 116, 124 hyperlinks, 577, 579
ABAP 7.31, 188 macros, 568
ABAP 7.4, 93, 110, 116, 129, 149, 153 multiple worksheets, 563
new features, 89 printer settings, 551
recommended reading, 157 recommended reading, 597
ABAP 7.5, 53, 89, 94 templates, 571
ABAP Channels, 751 testing, 558
general concept, 752 Access condition parameter, 276
ABAP Extended Program Check, 222, 238 Adapter pattern, 425, 510
ABAP in Eclipse SAP NetWeaver Agile development, 729
Development Tools for ABAP (ADT) Alias, 266
ABAP Managed Database Procedures (ADMP), ALPHA formatting option, 111
254, 257, 279 ALV, 546
Eclipse, 281 application, 756
ABAP Messaging Channels, 752, 753, 756 function modules, 507
coding the receiving application, 764 grid, 607
coding the sending application, 758 interface, 761
example, 768 list program, 317
framework, 761 report, 251, 420, 697, 751
SAP GUI, 755 SALV, 477
warning, 758 screen, 706
ABAP Push Channels, 752, 754, 771 Annotation, 62, 262, 349, 696
coding the sending application, 780 ANSI-standard SQL, 282
SAPUI5, 771 Application model, 488
ABAP Test Cockpit (ATC), 33, 145, 209, 210, Application settings, 437
289, 290, 305 Application-defined function, 493
recommended reading, 252 Artifacts, 47
SAP HANA, 211 Assemble/act/assert test, 179
ABAP Test Double Framework (ATDF), 195, ASSERT, 186, 334
197, 200 Association, 261, 654
ABAP to Word, 589 Asterisks, 99
ABAP Unit, 159, 211 Authority checks, 275, 371
ABAP Workbench, 33, 34, 52, 72, 429, 681
ABAP_TRUE, 117, 118
791
Index Index
B BRFplus (Cont.) Class-based exception, 322, 325 D

SAP Business Workflow, 467 CLEANUP, 326, 327
Behavior-driven development, 178, 207 simulations, 465 Clover, 71 Data changed event, 511
Big Data, 102 BSP (business server pages), 247 Code generator, 630 Data declaration, 111, 127
Bill of materials (BOM), 343 BSP application, 728 Code Inspector, 209, 211, 216, 231, 236, 305 Data definition, 176
BOOLC, 119 Buffering, 96 new features, 227 Data dictionary, 62
Boolean logic, 119 BUILD, 730 Code pushdown, 254, 289, 298 Data element, creation, 63
Boolean variable, 120 monkey logo, 729 AMDP, 296 Data provider class, 681
BOPF, 33, 114, 247, 341, 342, 634 tool, 728 CDS views, 295 Data type declaration, 104
action validations, 399 UI Editor, 733 locating code, 291 Data validation test, 184
actions, 392, 395 Business object, 358, 422 OpenSQL, 294 Data values, 372
and FPM, 651 CDS views, 349 techniques, 291 Database access, 90
authority checks, 370 manual definition, 342 Combined structure, 348 Database access class, 170
callback subclass, 416 Business rule management system (BRMS), Complex objects, 155 Database layer, 255
change document subnode, 415 427, 444 Component, 607 DCL (Data Control Language), 274
configuration class, 365 Business rules, 427, 430 Component configuration, 647 DDIC, 359
create header node, 345 ABAP, 434 Component controller, 629 configuration table, 454
create item node, 347 BRFplus, 435 COMPONENTCONTROLLER, 638 data element, 445
create model classes, 353 customizing tables, 432 Composition root, 350 field, 670
create object, 343 Business rules framework (BRF), 427 Conceptual thinking, 367 objects, 347
creating an action, 393 COND, 122 structure, 440, 611, 668
creating/changing objects, 357 Conditional formatting, 559 table, 263, 671
CRUD, 405 C object, 561 DDL, 258, 262, 267, 295
custom enhancements, 420 Conditional logic, 107, 116 definition, 285, 696
custom queries, 358, 359 Calling code, 49 Configuration table, 418 source, 287
delegated objects, 414 Calling program, 318, 481 Consistency validation, 403 Debugger, 73
determinations, 371 Cardinality, 269 Constructor injection, 171 Debugging, 142
locking objects, 369 CASE, 92, 116, 120, 121, 148, 266 arguments against, 172 Decision logic, 427
object, 692 CASE statement, 256, 266 Constructor operator, 114, 123, 131 Decision table, 449, 463
read object, 378 CDS views, 63, 247, 254, 256, 259, 350, 372, Container, 469, 513 Decision tree, 444
recommended reading, 425 534, 694, 698, 723 Contract violation, 198, 533 Delegated object, 413
testing, 419 buffering, 263 CORRESPONDING, 130 Dependencies, 160, 163, 190, 224
tracking changes, 411 building, 258 Coverage Analyzer, 226 breaking up, 164, 166
validations, 384, 386 definition, 273 Cross-origin resource sharing (CORS), eliminating, 161
wrappers, 423 extend view, 273 683, 722 identifying, 162
BOR object, 667 open, 295 CRUD, 360, 404, 680, 681, 694 Dependency injection, 190, 194
BRFplus, 384, 427, 435, 441 parameters, 273 Custom code, 254 Dependency inversion, 376
call in ABAP, 456 Change document, 416 Custom Code Management Cockpit, 250 Design by contract, 183, 311, 332, 335,
create application, 435 Changing parameter, 148, 489 Customer requirements, 438, 450 500, 533
decision table, 461 Channel extension, 761 Customizing settings, 162 class invariants, 336
decision tables, 449 CHECK, 376, 380, 389 Customizing table, 432 postconditions, 334
decision trees, 444, 448 Check method, 187 CX_DYNAMIC_CHECK, 316 preconditions, 334
enhancements, 472 CHECK_DELTA, 376, 378, 389 CX_NO_CHECK, 318 Design mode, 704
example, 458 CL_SALV_TABLE, 95, 479, 481 CX_STATIC_CHECK, 314, 315 Design Patterns
recommended reading, 476 Class invariants, 336 Elements of Resuable Object-Oriented
rule logic, 444 Class under test, 168, 189 Software, 342
792 793
Index Index
Determination, 378 Eclipse (Cont.) Feeder, 642 H

Determination pattern, 373 SDK, 79 Field catalog, 505, 523
Dialog box, 719 unit tests, 69 Field symbol, 137 Hard-coded restrictions, 267
Direct SQL read, 308 unused variables, 58 File Explorer, 540 Hashed key, 125, 144
Domain, 445 Eiffel, 334, 336 FILTER, 144 Hashed table, 126
Downcast, 146 Ellison, Larry, 253 Filter structure, 358 Head First Design Patterns, 170
Draft document, 411 ELSE clause, 266 FitNesse, 179 Helper class, 362
Dropdown menu creation, 739 Enhanced Syntax Check, 237 Flowchart, 431 Helper methods, 178, 499
Duplicate code, 54 Enhancement Wizard, 422 FLUID tool, 656 Helper variable, 112, 130
Dynamic check, 316 Entities, 666 FOR, 107 Hollywood Principle, 753
Dynamic exception, 316 Entity set, 669 FOR ALL ENTRIES, 228, 232 Host name, 722
Dynamic log point, 77, 79 Error, 720 Foreign key, 269 Hotspot, 491
DYNPRO, 246, 342, 352, 478, 599, 604, 623 Error function, 720 FORM routine, 44, 49
UI framework, 352 Error handling, 323, 328, 680 Formula node, 559
DYNPRO Screen Painter, 615, 617 method, 509 FPM, 33, 420, 599, 639 I
RESUME, 330 and BOPF, 651
RETRY, 329 floorplans, 639 ICF, 578
E Excel, 537, 732 GUIBBs, 642 IDocs, 663
and ABAP, 541 Guided Activity Floorplan, 640 IF/ELSE, 122
Early Watch reports, 209 and XML, 544 Overview Floorplan, 640 IF/THEN, 116
Eclipse, 33, 43, 258, 351 object creation, 542 Quick Activity Floorplan, 640 Importing parameters, 286
AMDP, 281 _EXCEL_WRITER, 544 recommended reading, 657 Importing table, 488
and SAP HANA, 258 Exception, 311, 313, 690 UIBBs, 642 Inbound plug, 626
and SAPUI5, 699 examples, 311 Fragment, 702 Index file, 746
bookmarking, 47 raising, 313, 323 Freestyle page, 734 Information/Warning/Error, 326
CDS view, 261 recommended reading, 339 Function, 437, 452 INITIALIZE, 493, 516
class constructors, 60 Exception classes, 311, 313, 315, 389, 691 Function module, 323, 324, 325, 515 Injection, 168, 171
connect to backend system, 40 choosing type, 318 signature, 325 automation, 190
create attributes, 59 constructor, 321 Functional method, 116 Inner joins, 98
create parameters, 59 creation, 320 Input parameter, 439
debugging, 72 declaring, 322 Integrated data access, 532
extract method, 54 design, 319 G Internal tables, 124, 366
Extract Method Wizard, 58, 65 types, 313 grouping, 140
features, 41, 65 Exception handling, 313 Gateway BOPF integration (GBI), 691 new functions, 137
help, 66 Exception object, 313, 324 Generic method, 424 Internet of Things (IoT), 752, 782
installation, 35 EXECUTE, 376, 382, 396 Generic User Interface Building Blocks Isolation policy, 753
Luna release, 67 Export parameter, 148, 334 (GUIBB), 642, 651
multiple objects, 45 Expression type, 444 GET_ENTITY_SET, 681, 687, 688
plug-ins, 79 Extended syntax check, 59 GitHub, 541 J
prerequisites, 35 External breakpoint, 688, 781 Global class, 69
Quick Assist, 52 God class, 481 Java, 33, 105, 659
recommended reading, 88 GROUP BY, 140 Java EE perspective, 701
refactoring, 59 F GUID, 301, 345, 366, 422 JavaScript, 659, 700
release cycle, 33, 45 key, 357 library, 662, 737
runtime analysis, 75 Factory method, 355 GuiXT, 748
SAP add-ons, 38 False errors, 223
Fast ALV Grid Object, 534
794 795
Index Index
JavaScript program, 46 MOVE-CORRESPONDING, 130, 131 P Root node, 373

Joe Dolce principle, 195 dynamic, 135 Rules engines, 428
MVC pattern, 247, 342, 352, 480, 494, 509, Pace layering, 354 Ruleset, 441
600, 651, 662 Parameter ID, 758
L controller, 480, 606 Parent node, 348
location of model, 601 Patterns, 113 S
Layout data property, 619 model, 480, 495, 601 PBO processing, 384
Lead selection, 630, 636 model as an assistance class, 602 PCP, 762 SALV, 478, 479
LET, 108 model declared in the controller, 603 Perspective, 79, 701 add custom icons, 512
LINE_EXISTS, 138 model inside the view, 602 Postcondition, 335 application-specific changes, 494
Local host, 721 view, 480, 603 Precondition, 335 CL_SALV_GUI_TABLE_IDA, 531
Local variable, 284 PREPARE, 396 concrete class, 481
Logging class, 60 Private method, 56, 174 create container, 486, 514
Logical condition, 446, 454 N Procedural programming, 160 design report interface, 484
Logical unit of work, 408 Procedure call, 472 display report, 507
Loop, 242 NativeSQL, 90, 304 Processing block, 142 editing data, 519
Nested sequential access, 243 Projects, 666 event handling, 491
NEW, 105 Prototype screen, 729 framework, 507
M No check, 316 Proxy, 721 grids, 522
Node structure, 612 calls, 663 initialize report, 487
Main header table, 300 Nugget, 81 servlet, 722 object editablitity, 520
Mapping object, 135 settings, 722 recommended reading, 536
Mass checks, 213, 224 Public method, 318 report, 502
reviewing, 220 O Push Channel Protocol (PCP), 760 SAP HANA, 534
running, 216 with IDA, 532
setup, 214 Obeo, 81, 87 SAP Business Suite, 248
Master data, 269 Design Studio, 87 Q SAP Business Workflow, 354, 467
Message object, 390, 762 Object authorization class, 370 SAP Code Exchange, 203
Message producer, 763 Object Linking and Embedding (OLE), 757 Query logic, 358 SAP Community Network (SCN), 34
$metadata, 687 object_configuration, 356 SAP Decision Service Management, 429
Method, 49, 53, 323 Object-oriented programming (OOP), 49, 145, SAP EarlyWatch Check, 751
Method call, 56, 338 169, 312, 324, 342, 424, 479, 480 R SAP ERP, 746
Method chaining, 111, 112, 198 OData, 663, 679 SAP Fiori, 725, 747
Method definition, 486 documentation, 685 READ TABLE, 128 SAP Gateway, 659, 663, 746
Meyer, Bertrand, 336 service, 697 Read-only mode, 527 coding, 680
Microsoft Excel, 537 Open source, 538, 737 REDUCE, 139 configuration, 666
Microsoft Open XML, 541 Open-closed principle, 285 Regular expressions, 129 create model, 665
Microsoft Outlook, 670 OpenSQL, 90, 254, 255, 256, 267, 291, 304 Remote function call (RFC), 663 create service, 673
MIME repository, 204, 571 new commands, 90 Report programming, 477 creating entities, 667
Mock class, 169 query, 91 Report RS_AUCV_RUNNER, 212 creating services and classes, 672
Mock objects, 160, 168, 176, 189 OpenUI5, 737 REST, 663 data provider class, 681
Mockup Loader, 203, 204, 541 open source, 737 Result method, 187 error handling, 690
Model, 691 ORDER BY, 234 RETRIEVE DEFAULT PARAM, 395 model provider class, 681
Model class, 342, 354, 360, 761 Outbound plug, 625 Return parameter, 469 service, 693
Model object, 83 Overlap check, 464 Return values, 154 Service Builder, 666
Model provider class, 681 Overview page, 646 RFC function module, 280 service implementation, 680
Module pool transaction, 610 testing, 678
796 797
Index Index
SAP GUI, 77, 151, 222, 477, 728, 753 SAPUI5 (Cont.) SPLASH BUILD The Pragmatic Programmer, 184
embedded, 75 architecture, 661 SQL, 686 Tooltip, 498, 504
Screen Painter, 733 browser support, 679 calculations, 93 Trace file, 76
SAP HANA, 101, 211, 253, 475, 534, 662, buttons, 719 queries, 92 Transaction, 627
686, 758 controller, 715 SQL for the web, 686 (/BOBF/TEST_UI, 384
ABAP table design, 299 Developer Guide, 738 SQL Monitor, 289 /BOBF/CONF_UI, 414
AMDP, 257, 279 fragment XML file, 710 SQL Performance Tuning Worklist, 289, 290 /BOBF/TEST_UI, 398
CDS views, 256, 257 function for testing, 721 SQL view, 262 /IWFND/ERROR_LOG, 688
code pushdown, 254, 288 functions, 717, 718 SQL-92 standard, 91 /IWFND/MAINT_SERVICE, 675, 677, 687
database views, 255 HTML file, 703 SQLScript, 257, 279, 282, 283 /SDF/CD_CCA, 226
database-specific features, 303 importing applications, 741 Stateful, 773 ATC, 216, 217
DDL, 258 JavaScript, 662 Stateless, 773 BOB, 343, 358, 393
Eclipse, 258 prerequisites, 664 Static check, 314 BOBF, 343
recommended reading, 309 recommended reading, 749 Static code check, 211, 228 BOBF/TEST_UI, 419
redundant storage, 299 storing applications, 744 Static method, 287, 765 BOBX, 343
secondary indexes, 301 testing, 721, 745 Stored procedure, 255 BOPF_EWB, 421
SELECT coding, 304 view, 702 String processing, 109 FPM_WB, 641, 651
stored procedure, 279 view and controller, 699 Structured variable, 397 IWFND/MAINT_SERVICE, 698
SAP HANA Cloud Connector, 724 XML file, 704 Stub objects, 168 MRRL, 101
SAP HANA Cloud Platform, 735 Search helps, 151 Subnodes, 349 RSSCD100, 420
SAP HANA Cloud Platform Cockpit, 725 predictive, 151 SWITCH, 120 SALV, 760
SAP HANA Rules Framework, 474 Sbastien Hermann, 587 Syntax check, 314 SAMC, 762
SAP Logon Pad, 85 SELECT, 234 System alias, 673 SAPC, 778
SAP Messaging Channels SELECT *, 230 SY-TABIX, 140 SAT, 75
activity scope, 760 SELECT statement, 101, 256 SATC, 289
receiver object, 766 Separation of concerns, 166, 210 SCDO, 412
subscriber object, 766 Service adaptation definition language T SCI, 209, 211
SAP NetWeaver Development Tools for ABAP (SADL), 695 SE03, 65
(ADT), 34, 695 Service Builder, 666 Table join, 101 SE11, 61, 151, 257, 265
SAP Process Integration (SAP PI), 347, service_manager, 356 Table work areas, 127 SE24, 85, 146, 320, 321, 429, 672
663, 765 SET_COLUMN_ATTRIBUTES_METHOD, 497 TCP protocol, 783 SE37, 85, 429
SAP Push Channels SETUP, 177 Technical columns, 498 SE38, 44
code for incoming messages, 774 Short dump, 64, 112, 113 Template SE80, 33, 41, 43, 71, 75, 152, 429, 609, 645
coding receiving components, 772 SICF framework, 691 customization, 726 SEGW, 666, 674, 691
testing the APC service, 778 SICF service node, 682 views, 261 SICF, 80, 578, 672, 678, 679, 772, 778
SAP S/4HANA, 248, 251, 253 Signature definition, 113 Word, 590 SIMGH, 675
SAP Screen Personas, 748 Simplification database, 249 Test class, 173, 180 SLIN, 58
SAP Solution Manager, 226 Single responsibility principle, 166 definition, 174 SLIN (ABAP Extended Program Check), 209
SAP Web IDE, 732, 748 Smart Forms, 587 Test code, 189 SM12, 370
cloud version, 724 Smart templates, 723 Test data, 182 SMW0, 204
menu, 728 SNOTE, 249 Test doubles, 153 SQLM, 289
templates, 723 Sort order, 506 Test injection, 168 SRTCM, 307
SAPlink, 80, 541 SORT statement, 239 Test methods, 177 ST05, 96, 276, 289
SAPscript, 247, 589 Sorted key, 144 Test seams, 164 ST22, 321
SAPUI5, 33, 296, 349, 420, 475, 600, 659, Sorted table, 126 Test value, 466 SWLT, 289
753, 781 Source code view, 44 Test-driven development (TDD), 69, 70, SWO1, 667
and Eclipse, 665, 699 Source mode, 705 159, 185 XLST_TOOL, 81
transaction_manager, 356
798 799
Index Index
Transactional view, 349 View, 622, 630 Z Z field, 300

Transient structure, 346, 372 View controller, 607 Z table, 104, 460
Transport request, 56, 468 Violated postcondition, 184 Z aggregated storage table, 102 ZCL_BC_VIEW_SALV_TABLE, 514, 521
TRUE/FALSE, 119 Violated precondition, 500 Z class, 43, 174, 356, 473, 522, 662, 694 ZCX_NO_CHECK, 316
TRY/CATCH/CLEANUP, 324 Z enhancement, 238
Type, 191
TYPE definition, 52 W
TYPE POOL, 103
TYPE REF TO DATA, 115 WDA
ALV grid, 599
application building, 607
U calling application, 627
coding, 628
UMAP, 81 component controller, 606
UML create component, 609
diagram, 81 data structures, 611
operation, 83 defining view, 619
Underlying grid object, 525 graphical screen painter, 604
UNION, 100 interface controller, 610
Unit testing, 71, 166, 173, 211 nodes, 613
ABAP 7.4, 153 PAI, 605
automation, 189 PBO, 605
executable specifications, 173 recommended reading, 657
mockA, 190, 195, 207 standard elements, 615
recommended reading, 207 storing data, 604
Usage Procedure Logging (UPL), 226 view settings, 613
monitoring job, 226 WDA Web Dynpro ABAP
User acceptance test (UAT), 179 Web Dynpro ABAP, 33, 83, 114, 247,
User command handling, 528 473, 599
User command routine, 761 Web Dynpro Code Wizard, 629
User commands, 488 WebSocket, 752, 754, 773, 774, 779
User exit, 473 WHERE clause, 94, 270
User Interface Building Blocks (UIBB), Window controller, 607
641, 651 Word, 595
freestyle, 642 Word macro, 591
Work area, 128, 241
Workflow, 468
V Workflow Builder, 468, 471
Validation, 386
coding, 388 X
creation, 387
Validation logic, 401 XML, 540, 543, 700, 702
VALUE, 106 code, 558
Variables, 102 files, 540
Variant configuration, 224 tree, 345
VBA (Visual Basic for Applications), 568 XSDBOOL, 119
800 801
First-hand knowledge.
Paul Hardy joined Heidelberg Cement in the UK in

1990. For the first seven years, he worked as an ac-
countant. In 1997, a global SAP rollout came along; he
jumped on board and has never looked back since. He
has worked on country-specific SAP implementations
in the United Kingdom, Germany, Israel, and Australia.
After starting off as a business analyst configuring the

good old IMG, Paul swiftly moved on to the wonderful world of ABAP
programming. After the initial run of data conversion programs, ALV
reports, interactive DYNPRO screens, and (urrggh) SAPscript forms, he
yearned for something more and since then has been eagerly investiga-
ting each new technology as it comes out. Particular areas of interest in
SAP are business workflow, B2B procurement (both point to point and
SAP Ariba-based), logistics execution, and variant configuration, along
with virtually anything new that comes along.
Paul can regularly be found blogging away on the SCN site and presen-
ting at SAP conferences in Australia (Mastering SAP Technology and the
SAP Australian User Group annual conference). If you happen to ever be
at one of these conferences, Paul invites you to come and have a drink
with him at the networking event in the evening and to ask him the
most difficult questions you can think of (preferably SAP-related).
Paul Hardy
ABAP to the Future
801 Pages, 2016, $79.95 We hope you have enjoyed this reading sample. You may recommend
ISBN 978-1-4932-1410-5 or pass it on to others, but only in its entirety, including all pages. This
reading sample and all its parts are protected by copyright law. All usage
www.sap-press.com/4161 and exploitation rights are reserved by the author and the publisher.

Abap Future

Uploaded by

Copyright:

Available Formats

Abap Future

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Abap Future

Uploaded by

Copyright:

Available Formats

First-hand knowledge.

ABAP Unit and Test-Driven

doesnt matter how pretty or object-oriented or well-encapsulated it is.

3 ABAP Unit and Test-Driven Development

In the traditional development process, you write a new program or change an

3.1 Eliminating Dependencies

3.1.1 Identifying Dependencies ENDFORM."Fire Nuclear Missile

3.1.2 Breaking Up Dependencies Using Test Seams * ELSEIF something_else.

* Some more business logic

3.2 Implementing Mock Objects METHOD fire_nuclear_missile."Test Method

* EXPORTING export_vlaue 3.2.3 Proper Injection

1. Enable testing of private methods. CLASS lcl_test_class DEFINITION FOR TESTING

Declaring Data Definitions ms_input_data TYPE zvcs_monster_input_data,

(Listing 3.16). CREATE OBJECT mo_class_under_test

METHOD return_a_bom_for_a_monster. cl_abap_unit_assert=>assert_equals(

Defining Custom Evaluations of Test Results

bom_item_details = mt_bom_data[ 3 ]. CLASS lcl_my_constraint DEFINITION.

cl_abap_unit_assert=>assert_equals( act = bom_item_details-part_ PUBLIC SECTION.

ENDMETHOD."Then Resulting BOM is correct Implementation

3.4 Automating the Test Process

DATA(class_in_type_details) = Error Handling

mock_monster_simulator ?= cl_abap_testdouble=>create( interface_name ). METHOD mocking_framework_test.

"Was the correct value returned?

In the running example used in this chapter, the CALCULATE_SCARINESS method

mock_monster_simulator->calculate_scariness( is_bom_input_data = ms_

To be more precise, the EVALUATE_MONSTER method of the LABORATORY object will

CATCH zcx_mockup_loader_error INTO loader_exception. 3.5 Summary

Head First Design Patterns

ABAP Test Double Framework

1 ABAP in Eclipse ......................................................................... 33

1.1 Installation .................................................................................... 35

2 New Language Features in ABAP 7.4 and 7.5 ........................... 89

2.1 Database Access ............................................................................ 90

5.4.4 Calling an AMDP from inside a CDS View ........................ 285

5 ABAP Programming Model for SAP HANA ............................... 253

B BRFplus (Cont.) Class-based exception, 322, 325 D

Determination, 378 Eclipse (Cont.) Feeder, 642 H

JavaScript program, 46 MOVE-CORRESPONDING, 130, 131 P Root node, 373

Transactional view, 349 View, 622, 630 Z Z field, 300

Paul Hardy joined Heidelberg Cement in the UK in

After starting off as a business analyst configuring the

You might also like