Lets check few basics of Test Driven Development as well as for ABAP Unit.
In this article, I would try to explain few basics of the ABAP Unit. In this series, I’m planning for these articles:
- ABAP Unit Test Driven Development Basic Example
- ABAP Unit Test Driven Development Basics
- ABAP Unit Test Fixture methods
- ABAP Unit Test Global class usage
- ABAP Unit Test Wizard to generate Test class – This article
- ABAP Unit Test Real time example
- ABAP Unit Test Advantages
What is TDD?
Test Driven Development is a process in which you rely on test to validate the functionality of the production code. In this process, tests are written first, then the actual production code to pass the tests. This test would be a separate code than the production methods. The production methods are also knows as Method Under Test and the class where production code is known as Class Under Test.
To develop the applications using TDD technique, we must have an automated Unit Test mechanism available in the programming language. With an introduction of the ABAP Unit framework in SAP from the ABAP release 6.20, it is now possible to use TDD technique in application development.
When working with TDD, you first write a empty code block (a shell) which would finally carry your Production Code. After that you write a test to validate the functionality with using Actual and Expected. After that you re-factor your production code to pass your test. At high level the process of TDD is a Cycle. Your code would go through many iterations of writing test, refactoring production code, and test execution.
Step would be:
- Write a Test
- Make Test Pass
Why to Write a Test First?
So you would think why to write a test first. When you start writing the test, you would start thinking of various aspects of requirement and start designing the production methods accordingly – Like defining the Attributes or parameters to the method. You would also think on the expected results based on the inputs e.g. If I pass x value, I would get x/2 which is my expected value. If you actual method is to Sum of the value as shown in the first article, you would know what is the expected value out of the method when you pass the inputs.
As you would have noticed in the example in first post, that I have used
#AU followed by the text. These are test properties – Risk Level and Duration.
Risk Level defines the risk of the test. When executing the test, system would check the risk level against predefined risk level in the Client settings. If your test has a higher risk level, ABAP Unit framework would ignore that test and will not execute that test. You can specify one of these three possible values:
- Harmless – The execution of this test doesn’t affect any existing processes or Database. This is default setting.
- Dangerous (Alarming) – This type of test makes changes to DB or persistent Data.
- Critical – This type of test would make changes to Customization as well as the Persistent data. A careful look is required.
Duration – Similar to Risk level, all the test would need to have expected runtime duration. ABAP Unit framework will not execute the tests with higher duration than defined in the client level configuration. For Duration, you specify these values:
- Short – Gets executed very fast. This is default setting at the client settings. Generally < 1 minute
- Medium – Gets executed in a bit. Little bit extra time than the short duration. In the range of 1 minute to 10 minutes
- Long – takes a while to process the test. The execution time would be more than 10 minutes
Specify test properties, As of Release 700
CLASS Abap_Unit_Testclass DEFINITION FOR TESTING "#AU Duration Short "#AU Risk_Level Harmless .
Specify test properties, As of Release 702 (Release 7.0 Enhancement Pack 2)
CLASS Abap_Unit_Testclass DEFINITION FOR TESTING DURATION SHORT RISK LEVEL HARMLESS .
Client Based Configuration
You can maintain the client based configuration for switch off Unit Test, allowed preference for Risk level and Duration in the transaction SAUNIT_CLIENT_SETUP. You must not change the settings on the fly as all of your tests may become non-executable because they are having different Risk Level and Duration than defined in the settings. Setting screen looks similar to this:
FOR TESTING Keyword
The addition Testing is important when defining the test class. If you omit the addition, your class would be considered as a simple production class. The
FOR TESTING addition makes it a test class. You would also need at least one method with addition FOR TESTING.
Class CL_AUNIT_ASSERT has various methods to test various different scenarios. Most used method is ASSERT_EQUALS. This method takes Actual and Expected values as an argument and tells the Unit Framework if the tests is passed or failed. Over the next various articles, I would leverage few of the methods from the class to validate the test.
In the next article, I would cover Test Fixture methods. Stay tuned!