Aunits for RAP
Aunits:
AUnits are unit tests written by ABAP developers to test each functionality of
their code. In RAP, AUnits are used to test functionalities such as validations,
determinations, actions, and CRUD operations etc. Your AUnits should aim
for maximum coverage of your code. It is recommended to follow TDD (Test
Driven Development), where you write the test cases first and then
implement the logic. This ensures that the test cases are based on the actual
requirements and are not influenced by the implementation.
Refernce link for TDD:
https://help.sap.com/docs/abap-cloud/abap-development-tools-user-
guide/test-driven-development-with-abap-unit
https://youtu.be/k8NaW8wUGp8
Basics of Aunits:
Test classes can be either local or global. Unit tests should typically be
implemented as local classes within the program object that is being tested.
However, you can use global test classes to host reusable logic for unit tests
across different programs. In Eclipse ADT, there is a separate environment for
managing local test classes
Refer this link to learn basics: https://learning.sap.com/learning-
journeys/acquire-core-abap-skills/implementing-code-tests-with-abap-
unit_b23c7a00-c2e8-406d-8969-b00db3f1fd87
Structure of test class:
1
For Testing: The addition FOR TESTING is used to identify a test class.
These are the classes that will be executed when you run ABAP Unit
tests. I will explain further how AUnits are triggered and how to execute
them.
Risk Level
CRITICAL:The test changes system settings or customizing data.
DANGEROUS:The test changes persistent data.
HARMLESS:The test does not change system settings or persistent
data.
Duration
SHORT:Execution time is imperceptible, expected to take only a few
seconds.
MEDIUM:Execution time is noticeable, around a minute.
LONG:Execution time is very noticeable, taking more than a minute.
Methods in Test Classes
Helper Methods: Helper methods are ordinary methods of the test
class. They are not called by the ABAP Unit framework. You can use
helper methods to structure the code of your test methods.
For example, prepare_testdata is a helper method.
Test Methods:Test methods are defined with the addition FOR
TESTING after the method name. Each test method represents one
test. The ABAP Unit framework performs this test by calling the
corresponding test method. Test methods must not have any
parameters. In the above example, aunit_for_cds_method is your
test method.
Good Practices
It’s a good practice to have a separate method for each functionality,
with no dependencies inside the method. Each method should be
treated as a single test case.
Always include both positive and negative test cases.
2
Flow of test case:
CLASS_SETUP
This static method is executed once before the first test of the test
class.Use this method for fixtures that are time-consuming to create
and for which you are sure the settings will not be changed by any of
the test methods.
Example: Setting up a test double in the test environment.
SETUP
This instance method is called before each test of the test class. Use
this method for fixtures that you want to create fresh for every test
case.
Example: Creating an instance of the CUT (Class Under Test).
TEARDOWN
This instance method is called after each test of the test class.Use it to
undo changes made in the SETUP method.It is especially important if
SETUP modifies persistent data (such as system configuration,
customizing, or master data).
Example: Clearing test doubles so that each test starts with fresh data.
CLASS_TEARDOWN
This static method is executed once after the last test of the test class.
Use it to clean up or destroy the test environment set up in
CLASS_SETUP, once all tests are completed.
Example: Tearing down the overall test environment.
3
How do we run test class:
To run abap units execute abap unit test. This will trigger the test class. If you
run abap application it will not trigger test class.
Test double framework:
As I mentioned earlier, your unit tests should check only the functionality
(CUT – Code Under Test) that you have written the test case for. However, in
real-world scenarios, each component is usually interlinked and not
standalone.
What is the issue?
To explain this, let’s take an example. Suppose you are testing an instance
authorization method. This method is dependent on an authorization object.
If the AUTH-CHECK of the authorization object fails, the instance
authorization method will also fail. This means that even if your instance
authorization method is working correctly, the test could still fail due to its
dependency. Ideally, the failure of a dependency should not cause your unit
test to fail when you are testing the functionality of the CUT itself.
Examples of dependencies in RAP
Instance and global authorizations: Dependency on authorization checks.
SAVE / SAVE_MODIFIED methods: Dependency on function modules or
BAPIs.
Determinations: You might use EML of another BO, making your BO
dependent.
Validations: Your CDS view could be a dependency; if the required record is
not present in the CDS view, the validation might fail.
And there are many more such cases.
4
Solution — Test Double Framework
So, how do we overcome this? Instead of relying on dependencies that are
beyond our control, we mock or stub these dependencies. This allows us to
influence how they behave and interact during testing, thereby avoiding test
case failures due to external dependencies. This approach is implemented
using the Test Double Framework.
The main purpose of both mock and stub is to not to test from actual data
but rather a fake data that we can configure. Because our test class will fail if
its dependent on real time data as it will be different in different
environment.
1. STUB: Stubs just provide predefined response.
2. MOCK: You design how the interaction should be. Like if you provide
this value this is how the output would be and also verify it.
In this documentation I will be primarily focusing on Aunits for Rap. If you
want to learn for other objects aswell refer this video:
https://www.youtube.com/watch?v=nuuqy5CniTs&t=3143s
I will now discuss in detail how we write ABAP Unit tests with a simple example.
Requirement:
Write a positive test case to check the validation check_country, which
should throw an exception if we pass a country code with more than 2
characters. Also, remove the dependency on the CDS view.
5
Steps
Identify CUT and dependencies
Here, I have taken a validation method as an example for testing. The CUT
(Code Under Test) is the validation method, and the dependency is the CDS
view. So, I will use the STUB methodology to configure the response of the
CDS view.
Creation of test class
Once you create the test class, you need to add it as a friend in the local
handler class (since we are testing a validation). This is necessary because all
the methods of the local handler class are inside the private section and
cannot be accessed directly.
Inside the test class
I have already explained the use of SETUP, CLASS_SETUP, TEARDOWN, and
CLASS_TEARDOWN earlier, so I will not repeat that here.
In this example, validate_check_country is our test method. I have added a
test double for the CDS view, because the validation should be tested using
the mock data we provide, not the actual data.
I create the mock data and insert it, so that the CDS view returns this data.
Now, when we pass parameters to the validation, we can check if we get a
value in reported, since we have provided a country code with 3 characters.
Note: This is just an example program. Typically, mocking, adding mock data,
and different functionalities would be implemented in separate methods. It
is not a good practice to combine everything into a single method. Each
method should have only one responsibility. Here, I have combined them
solely to showcase the concept.
6
7
