Test Driven Development with ABAP

[Former Member]

Introduction into TDD

The main idea of TDD is: write test code first, run it, see it fails, code implementation, run tests, verify its ok, repeat. This approach leads to a very clean code, doing exactly what’s it’s supposed to do, with emphasis on the coding to interfaces, not classes. You can find lots of info about TDD here

ABAP Unit

6.40 Release of SAP R/3 system comes with ABAP Unit, which is actually the clone of the famous JUnit and NUnit. There are some peculiarities, though. First of all, you can code ABAP Unit tests only as local classes. So, that means you can have them inside:

1. Report
2. Normal ABAP Objects Class(also known as global)
3. Function module

Code Example
class lcl_test definition for testing inheriting from cl_aunit_assert.  public section.    methods:      test_animal for testing.endclass.                    "lcl_test DEFINITIONclass lcl_test implementation.  method test_animal.  data l_instance type ref to if_ss_abapunit_test.  l_instance = cl_ss_abapunit_test=>get_instance( ).  assert_not_initial( msg = 'Getting instance of cl_ss_abapunit_test' act = l_instance ).  data animal type string.  animal = l_instance->get_animal( ).  assert_equals( msg = 'Expecting a fox' exp = 'Fox' act = animal ).  endmethod.endclass.
Class is declared as “for testing inheriting from cl_aunit_assert”. In this class methods, starting with “test” are defined. So, all of these methods would be executed upon test run. Test run can be started with Ctrl-Shift-F10, or from dropdown menu, after the right-click on your class/report/function module.

Granularity

Nobody prevents you from doing functional testing of the business logic of your application with ABAP Unit. You write your tests against a certain exposed API, thus verifying that it works as expected, providing example of usage; thus you kill a pack of rabbits with one shot: how-to-use documentation, regression testing ensuring that your team doesn’t break expected functionality during new development or maintenance, and feeling of security when your refactor your application.

Test suites

Question of organization of a set of unit tests should be considered early. I prefer to put all related ABAP Unit tests into one package. In such a way, I can run them all at once, using SCI transaction. This is especially helpful when you refactor something. Backed up by a set of unit tests, which you run in SCI transaction with every significant change you make, you feel yourself sure and secure that your changes do not break functionality of other applications, which rely on yours. Of course, people who use your application should know about this contract you establish – sets of unit tests define behaviour of the application you develop, ideally according to the use cases.

Conclusion

Hope this short installment would influence your approach to development with ABAP Objects in your next project. Anyway, feel free to talk back.