Skip to Content

TDD Experiment: The Beginning

I decided to get more familiar with Test Driven Development. In fact I don’t have much experience with TDD and I have no coach so it will be a long way.  But let me define what I want to do within the next few months:


  • I change an application I’m running existing unit tests.
  • Before I start coding I define      test cases.
  • Then I code exactly the things      I need.
  • When I’m ready I re-run my      tests and add some additional unit test.
  • Later I do code refactoring.



At first I asked some of my collegues whether they will join the experiment and in fact they promised to join my efforts. They will even enlarge the TDD scope to answer following questions:


  • Which development platform are      suited for TDD? Can we even work with TDD in migration projects that use      ETL-tools?
  • Can we apply TDD in the context      of architecting? Is there a kind of “Test Driven Architecting”? Is it a      proper way to define test-cases for any architecture first so that      validation of an architecture is easy to do?


The First Experiment: Development of a BOR-Object


But now back to ABAP development. I had to define a new business object (in fact those old fashioned BOR-objects) and a collegue hat to integrate them into an existing framework. Instead of writing a spec we did the concept together using out wiki. We wrote down some requirements and after some minutes we could drill down our activities and write a list of tasks. Every task took at most one hour.


We decided, that we want to code a very slim BOR-object and to delegate the functionality to a ABAP object. There are a lot of reasons for it: the editor for BOR-objects is terrible and the workbench support in general in much much better. We found some names for the classes to code and put it into the wiki.

Then we created the classes and methods together with method parameters in a kind of pair programming. In fact this was the interface – I do the implementation of the methods and my collegue had to integrate them into the framework.


After I was alone I felt that I wanted to do the implementation first but I stopped myself from doing so. But how to test a BOR-Object? There seemed to be no way to do integrate unit test into BOR although I thing we could define some complicates TRMAC-macros that would help us… but who wants to use TRMAC? Of course I could write some unit tests for my class but I wasn’t sure whether this would made sense because the most complicated thing in BOR-programming are those asynchronous processes from the workflow runtime.

So I decided to write an old-fashioned report that simulates the behaviour by throwing BOR-events in an old way so that I could create the object and perform some simple invocations.  Later I did the implementation and ran the my report again and it dumped: I realizes that I forget an important parameter in my interface definition. I added it and mailed my collegue to fill that parameter.


Then I run the report again and it showed the correct result: A workflow was created and I found a work item within my inbox. I was happy because now I have an implementation and a way to test it. I added the name of my report in the wiki – later I will put the whole stuff and integrate into existing documentation.


Rethinking what I did…



I think next time I will do better. Of course I can test my BOR-object this can’t be done automatically. In fact there is another drawback: My BOR-object implicitly uses a lot of customizing and if this not available our programs will crash. So creation of an object together with some basic operations is an important test case – even if the object is not written to the database because my unit test should be no integration test. Tomorrow I will create a unit test that covers this test case.

I learned that it takes a lot of discipline to write test cases first – especially when you coded the implementations first like I did the last 15 years. I’m asking how long it will take until my coding habits will change. But if this changes – will I be able to switch back if to classical coding style if someone wants me to do so?

You must be Logged on to comment or reply to a post.
  • Hi Tobias,
    from Archaeopteryx to Tyrannosaur: It’s easy to test BOR objects even without building a workflow. The following link leads you to a description in the SAP Library about accessing the methods and attributes of BOR objects inside your own programs.
    The standard procedure uses macros defined in an Include program, which may be a problem within a Unit Test class. But each of the macros encapsules a function module, so you can easily use FMs such as SWO_CREATE or SWO_INVOKE to write your Unit Tests.
    The sad fact that BOR objects don’t support static type safety makes it even easier to write the Unit Test beforehand. 😉
  • Hi Tobias,
    never had the heart to do this kind of development (yet). Maybe I have to do it later in my current project. It’s hard to change a “hard coded” developing method for old coders like us 😉

    BTW: BOR Objects are not needed within workflows anymore. You can call OO methods direct from the WF tasks now. Works great and it’s much easier to test.

    Regards, Uwe

    • Hi Uwe,

      yes, of course there is IF_WORKFLOW but it supports only Business Objects with a key-length up to 32 characters.

      In most cases this should be enough and in BOR-objects working on you own transparent tables it should be easy to add a GUID as attribute. In fact a lot of SAP applications like SAP BP have an NRIV-key as well as GUIDs living side by side together.

      But in my case I decided no to change the application and so BOR was an “appropriate solution”. Nevertheless I think transparent tables that have keys consisting of 40 or even 60 characters are propably a design error.


  • ABAP Unit should be used to test the smaller unit of your code. It should not be used to test your full functionality.

    ABAP Units especially for BOR objects:
    In business objects, you must have some methods i.e. GET_LIST
    This method may have the API function, Function Module, Report etc to achieve the functionality. i.e. API function Z_GET_LIST

    You should write an ABAP unit on this function module to test if your code is working as you expected. E.g. In your FM Z_GET_LIST you need to collect the records and derive the total based on the primary key. So, what you do in TDD is:
    1. Create a empty subroutine i.e. GET_SUM with the parameters Input table and output table.
    2. Write a Unit Test
    a) Fill the input table with dummy data
    b) Fill the expected table with the result you are expecting
    c) Call the Subroutine get the with the dummy input table and empty actual output table
    d) Check if your expected table and actual table are matching using the method call CL_AUNIT_ASSERT=>ASSERT_EQUALS
    e) It will fail the test since you don’t have any logic in your GET_TOTAL subroutine
    3. Now implement your logic in the GET_TOTAL and re-run your test.
    4. If test fails change your code in GET_TOTAL and rerun the test. Repeat this step until your test passes.

    In turn we are checking the smaller part of the functionality, but not the full functionality.

    Naimesh Patel

  • Hi Tobias,

    maybe next time you could do it this way:

    1) Your colleague and you write together some simple unit tests against a non-existing interface. The tests are the definition for the interface specs (no need for the wiki). Now, you have tests but they do not compile -> Interface does not exist.
    2) Your colleague creates the interface and is finished once the tests compile -> The interface conforms with the spec.
    3) Now, you can add the implementation.