Wood J. Object-Oriented Programming with ABAP Objects

Подождите немного. Документ загружается.

ABAP Unit Overview

no understanding of the code used to implement the functionality under test.

Unit tests, on the other hand, should be "white box" tests designed by devel-

opers with intimate knowledge of the code used to implement the module in

question. This inside knowledge provides broader test coverage, testing hid-

den pieces of logic that are often difficult to analyze in a functional test.

• Each of the ad hoc techniques described earlier requires a fairly significant

amount of manual effort to set up the test and execute it. These efforts repre-

sent wasted time for developers that could be moving on to new development

tasks, projects, and so on.

• It is difficult to document and interpret the test results. After all, how do you

document a debugging session? Often, the documentation effort boils down to

the tedious process of capturing screenshots that must be accompanied with

step-by-step narrative text.

• Ad hoc tests are difficult to reproduce because it is too easy to neglect to per-

form some basic setup task or skip over a step in the overall test sequence.

Recognizing these types of problems, Kent Beck

decided to develop a unit testing

framework that could be used to provide some of the common elements neces-

sary for building and running automated unit tests. The first incarnation of this

framework created for the Smalltalk language was called SUnit. Since that time,

this same testing model (colloquially known as xUnit these days) has been

adapted to create testing frameworks for other languages such as Java (JUnit),

.NET (NUnit), and with the SAP NetWeaver 2004 release, ABAP Objects. The SAP

implementation of the xUnit test framework is called ABAP Unit.

9.1.2 Unit Testing Terminology

To understand how to use ABAP Unit, it is important to define some of the basic

terms that are used throughout the framework (see Table 9.1). These terms (and

concepts they represent) are largely based on concepts outlined in the core xUnit

framework.

2 Kent Beck is the creator of Extreme Programming, a software engineering methodology that,

among other things, advocates test-driven development using automated unit tests.

235

9 | Unit Testing with ABAP Unit

Term Description

Test Class A test class defines an environment for running multiple related unit

tests (implemented as test methods).

Test Method Test methods are special instance methods of a test class that can be

invoked to produce test results. In the xUnit framework, a test

method represents a single unit test.

Fixture A fixture defines an environment for running unit tests in the proper

context. Fixtures are configured in special callback methods defined

within a test class. You can insert code in these methods to obtain

and clean up the resources (e.g., file handles, connections, etc.) that

are used within the unit test methods.

Test Task A test task groups test classes together, allowing their methods to

be executed together in a single test run.

Test Run A test run controls the execution of a test task. Test runs produce

test results that can be viewed in the ABAP Unit result display.

Assertion Inside a test method, individual logical tests are made to assess the

correctness of a particular piece of functionality. Whenever these

tests are completed, the actual results of the test need to be com-

pared with expected results to determine whether or not the test

was successful. The ABAP Unit framework supports you in this com-

parison process by providing a common utility class called

CL_AUN I T_ASSERT. which has many useful methods for affirming the

correctness of a given logical test.

Table 9.1 Basic ABAP Unit Terminology

9.1.3 Understanding How ABAP Unit Works

The ABAP Unit test framework is tightly integrated into the ABAP Workbench,

making it very easy to set up and execute tests for a given ABAP program. From

a development perspective, ABAP Unit tests are nothing more than local classes

defined within an ABAP program (i.e., an executable (or reportl program, module

pools, class pools, function groups, etc.). These classes contain special parameter-

less instance methods that perform the actual tests, verifying their results with

utility methods from class CL_AUNIT_ASSERT.

Tests can be run individually via various menu options in the ABAP Workbench,

or en masse via integration with the Code Inspector tool (Transaction SCI). In

236

Creating Unit Test Classes

either case, the actual tests are grouped together inside of a test task that is exe-

cuted in a test run. During the test run, the individual test methods of the test

classes are executed separately by a test driver in the ABAP runtime environment.

However, before the test method is called, the runtime environment will search

for a special method called setup in the test class. If the setup method exists, the

runtime environment will call it before it calls the test method to ensure that the

test is set up properly. Similarly, after the test method completes, the runtime

environment will execute the teardown method if it exists. This important feature

of the framework makes sure that each test runs independently, helping you to

identify subtle bugs related to unforeseen dependencies between methods, and

so on.

The outcomes of the various tests are shown in the ABAP Unit results display. The

details shown in the ABAP Unit results display provide information about what

went wrong, and where. The details are context-sensitive, allowing you to navi-

gate within the ABAP Workbench to the source of the problem.

9.2 Creating Unit Test Classes

For the most part, you define and implement test classes in the same way thatyou

would build a regular ABAP Objects class. However, test classes and test methods

must be defined using the FOR TESTING addition. Listing 9.1 shows the basic form

of an ABAP Objects test class definition.

CLASS lcl_my_test_class DEFINITION '0AU Risk_Level Harmless

FOR TESTING. "#AU Duration Short

[...]

ENOCLASS.

Listing 9.1 Basic Form of ABAP Unit Test Classes

As we stated previously, you define test classes as local classes in your ABAP pro-

gram

. At first glance, this might not seem like a very safe practice because you

run the risk of transporting some potentially dangerous test code into a produc-

3 As of Release 7.0 of the SAP NetWeaver Application Server, you can also create global test classes.

Global test classes must be defined as abstract, arc not allowed to have fixtures, and can only be

used in local test classes. Given these limitations, we will not investigate the use of global test

classes in this book.

237

9 | Unit Testing with A8AP Unit

tive environment. However, the FOR TESTING addition effectively divides the pro-

gram into two separate parts: testing code and production code. Test code is typ-

ically not even generated in production systems (controlled by the AS ABAP

profile parameter abap/test_generation). And, even if it is. the test framework

will not execute an ABAP Unit test run in a production client. So. developers can

rest easy knowing that their test code will not wreak havoc in a productive envi-

ronment.

9.2.1 Test Attributes

When defining a test class, you must specify a couple of attributes that are used

by the ABAP runtime environment during the execution of

test. In local classes,

these attributes arc not traditional attributes in the sense that they are defined

using the

DATA

statement. Instead, they are defined as special pseudo comments

added after the

CLASS

statement.

In Listing 9.1, you can see both pseudo comments added to the definition of local

test class lcl_my_test_class. The Risk_Level attribute describes the effects that

the test could have on the system. For example, it is possible that test methods

might invoke functionality in the programs under test that could result in changes

to the database, and so on. Test classes that introduce this kind of risk can be

restricted for execution based on client customizing settings (defined in the

Implementation Guide (IMG) or in Transaction SAUNIT_CLIENT_SLTUP). This

way, for example, you can protect

golden client from test side effects that could

impact other project efforts. The possible values for the Risk_Level attribute are

shown in Table 9.2.

Risk Level Potential Side Effects

Critical Could alter system settings, customizing, and so on.

Dangerous Could change records in the database.

Harmless No side effects; the test is innocuous.

Table 9.2 Risk Level Attribute Values

The Duration attribute specifies the expected execution duration of a test class.

This attribute helps the ABAP runtime environment to know when a test has run

too long (perhaps due to an error in the test code such as an infinite loop). The

238

Creating Unit Test Classes

possible values of this attribute are Short, Medium, and Long, and they have default

values of

minute, 5 minutes, and an hour, respectively. These default values can

also be adjusted in Transaction SAUNIT_CLIENT_SETUP.

9.2.2 Test Methods

Test methods are defined as parameterless instance methods in a test class. The

signature of these methods also requires the FOR TESTING addition (see Listing

9.2).

CLASS lcl_my_test_class DEFINITION "#AU Risk_Level Harmless

FOR TESTING. "#AU Duration Short

PRIVATE SECTION.

METHODS:

test_methodl FOR TESTING.

test_method2 FOR TESTING.

ENDCLASS.

Listing 9.2 Defining Test Methods

Each test method in a test class corresponds to a single unit test. Consequently, a

test method should concentrate on testing a single software unit (e.g., a method,

a function module, etc.) rather than testing an entire application. It is important

to keep unit tests granular so that we can focus in closely on potential bugs that

might creep into various parts of the program. Most of the time, the implementa-

tion of a test method will simply consist of a single call to a module of the pro-

gram under test followed by a status check using utility methods defined in class

CL_AUNIT_ASSERT.

Ifyou look closely at the code in Listing 9.2, you will notice that the test methods

have been defined in the private section of the test class. This is by design because

test classes implicitly share a friendship relationship with the test driver of the

ABAP runtime environment. Consequently, you should prefer to define your test

methods in the private or protected sections of your test class.

9.2.3 Managing Fixtures

Test classes group related test methods (i.e., unit tests) together into a logical unit.

In these classes, you can also define special fixture methods that help set up and

teardown unit tests. These methods have predefined names that are automatically

239

9 | Unit Testing with ABAP Unit

recognized by the ABAP runtime environment. Each method is defined in the pri-

vate section of the class and has no parameters. Table 9.3 describes the various

types of fixture methods that arc supported by the ABAP Unit framework.

I Method Name Usage Type I

setup This instance method is called prior to the invocation of every

test method in the test class.

teardown

This instance method is called after every invocation of a test

method in the test class.

class_setup

This class method is called once before any test methods are

called in the test class.

class_teardown

This class method is invoked after all of the test methods in

the test class have been called.

Table 9.3 Fixture Methods and Their Usages

Fixture methods are an excellent place for defining common initialization code

that is relevant for all of the test methods in a test class. In particular, the instance

methods setup and teardown provide a useful hook for implementing code that

ensures that each test is executed independently using the proper runtime config-

uration.

9.2.4 Generating Test Classes for Global Classes

You can generate test classes for global classes using the test class generation tool

provided with the Class Builder. To access this generation tool, select the menu

path UTILITIES • TEST CLASS GENERATION in the Class Builder. This brings up the dia-

log box shown in Figure 9.1. Here, you are presented with options for specifying

the unit test class attributes, generating test methods, and so on. You can access

the generated test class by selecting GOTO • LOCAL TEST CLASSES in the menu path

of the Class Editor screen of the Class Builder.

240

Case Study: Creating a Unit Test in ABAP Unit

cuss Interface ZCL.CUSTOKR |

Propels interfaces Friends Aai.tiulcs

a P*ame«rs

BJBI

laimm II

rr*

ZIF_COHPARAfitE-COliPARC_T(ll»$TA»iCPUBll Conpvi Two OWects To Deterrrw* The* Order

CONSTRUCTOR IHSTMiCPUBl I CONSTRUCTOR

AS.STRIH6 INSTANtPUBll OrtpUfthe CuSWrner

&Menjd selection tw

»est

class generator

ioca< Test Class

Cuss Name

ASAPJJWT.TESTCLASS

AS.STR1NO

Z)F_COMPARABLE -COMPARE.TO

• X

IBS

Options

@ Generate Method C«s

0 Generate Assert Equar

v*iditr Period Category

ass

R.sk Lenil

Harriets

Figure 9.1 Generating a Test Class in the Class Builder

9.3 Case Study: Creating a Unit Test in ABAP Unit

Now thatyou have a basic understanding of how to create unit test classes, let's

consider an example. The program ZUNITTEST in Listing 9.3 defines a simple class

called 1c1_account that is used to represent a bank account. It also defines a test-

ing class called lcl_account_test that contains a single test method called

test_transfer that is used to test the behavior of the transfer method defined in

class lcl_account. The environment for this test method is established in the fix-

ture method setup, which instantiates and initializes two account objects called

I r_checking and lr_savings, respectively. Inside the test method, we attempt to

transfer $1,000 from the checking account into the savings account using the

transfer method. Because this method can throw an exception of type

Icx_insuff icient_funds, this method call is wrapped inside a TRY statement. If

this type of exception docs occur, it would be because the fixture was set up

241

Unit Testing with ABAP Unit

incorrectly in the setup method. In this event, there is no point in proceeding

with the test, so you use the

FAIL

method of class

CL_AUNI T_ASSERT

to terminate

the test with an error.

REPORT zunittest.

CLASS 1cx_insufficient_funds DEFINITION

INHERITING FROM cx_static_check.

ENDCLASS.

CLASS 1cl_account DEFINITION.

PUBLIC SECTION.

DATA: accountjd TYPE numc5 READ-ONLY.

balance TYPE bapicurr_d READ-ONLY.

METHODS:

constructor IMPORTING im_acct_id TYPE numc5.

deposit IMPORTING im_amount TYPE bapicurr_d.

withdrawal IMPORTING im_amount TYPE bapicurr_d

RAISING lcx_insufficient_funds.

transfer IMPORTING im_amount TYPE bapicurr_d

im_to_account TYPE REF

TO lcl_account

RAISING lcx_insufficient_funds.

ENDCLASS.

CLASS lcl.account IMPLEMENTATION.

METHOD constructor.

accounted - im_acct_id.

ENDMETHOD.

METHOD deposit.

balance - balance + im_amount.

ENDMETHOD.

METHOD withdrawal.

IF balance LT im_amount.

RAISE EXCEPTION TYPE lcx_insufficient_funds.

ENDIF.

balance - balance - im_amount.

ENDMETHOD.

METHOD transfer.

242

Case Study: Creating a Unit Test in ABAP Unit 9-3

IF balance IT im_amount.

RAISE EXCEPTION TYPE lcx_insufficient.funds.

ENDIF.

1m_to_account->deposit( im_amount ).

ENDMETHOD.

ENOCLASS.

CLASS 1cl_account_test DEFINITION

FOR TESTING.

PRIVATE SECTION.

DATA: lr.checking TYPE REF TO

lr.savings TYPE REF TO

METHODS:

setup.

test_transfer FOR TESTING,

teardown.

ENOCLASS.

CLASS 1cl_account_test IMPLEMENTATION.

METHOD setup.

CREATE OBJECT lr_checking

EXPORTING

im_acct_id - '10000'.

CREATE OBJECT lr_savings

EXPORTING

im_acct_id - '20000'.

lr_checking->deposit( '1500.00' ).

1r_savings->deposit( '500.00' ).

ENDMETHOD.

METHOD test.transfer.

TRY.

CALL METHOO 1r_checking->tran$fer

EXPORTING

im_amount - '1000.00'

im_to_account - lr_savings.

CATCH lcx_insufficient_funds.

CALL METHOO cl.aunit_assert->fai1

"i?AU Risk_Level Harmless

"#AU Duration Short

lcl_account.

243

9 | Unit Testing with ABAP Unit

EXPORTING

msg - 'Insufficient funds...'.

ENDTRY.

CALL METHOO cl_aun1t_assert->assert_equals

EXPORTING

act - 1r_savings->balance

exp - '1500.00'

msg - 'Savings account not credited correctly.'.

CALL METHOO cl_aunit_assert->assert_equa1s

EXPORTING

act - 1r_checking->balance

exp - '500.00'

msg - 'Checking account not debited correctly.'.

EN0METH0D.

METHOD teardown.

CLEAR: lr_checking. lr_savings.

ENDMETHOD.

ENDCLASS.

Listing 9.3 A Simple Unit Test Example

Assuming the call to method transfer does not raise an exception, you check the

results using the ASSERT_EQUALS utility method provided with class CL_AUNIT_

ASSERT. This method compares the actual value of the balance attribute of each

account object with the value you would expect each account to have after a suc-

cessful transfer operation. In the following Section 9.4, Executing Unit Tests, you

will see that this particular test discovers an error in the logic of the transfer

method. Also, notice that an implementation for the teardown fixture method is

provided in class lcl_account_test. Here, the fixtures used in the test_transfer

method are being cleaned up. Now, if you decide to add additional test methods,

you can be sure that the attributes

r_checking and

r.savings are properly ini-

tialized before they arc used in a unit test.

9.4 Executing Unit Tests

After you have created your unit tests in ABAP Unit, you can run them in several

different ways. In the following subsections, we will look at options for perform-

244