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?