Unit test automation: A step towards Agile delivery and DevOps in SAP

[jamesroberts]

With the constant demand to develop and change SAP applications faster, the need for continuous delivery has never been greater.

Agile, continuous delivery and DevOps have been commonplace in many IT organizations for some time now and the need to apply these concepts to SAP is starting to catch on.

But what effect will that have on the way development is done in SAP?

 

Continuous Integration

One of the core concepts in DevOps is that of Continuous Integration (CI).  When code is changed, unit tests are automatically executed to verify its quality.  The goal is to identify problems and bugs early in the development lifecycle so they don’t cause issues later in QA or worse, in production.

A good definition of CI is here.

Planning and executing unit tests is time-consuming and tedious, so a solution to automate it would seem like a no-brainer.  So why don’t we see this being done very often in SAP?

 

SAP development is different, but unit testing is still relevant

Outside of SAP development, CI ensures that changes are built and verified via automated unit tests when a developer checks their local code into the central repository.  If something has broken the build, developers are informed quickly so they can implement the necessary fixes.

SAP, and particularly ABAP, is different as we know as all development is carried out in a shared system.  Any changes are then immediately visible, and affect, everyone.

Unit testing capability exists as standard within SAP, so how can we start using it effectively to implement CI processes?

 

Unit testing and test-driven development (TDD)

Firstly let’s understand what unit testing is about.  Essentially we’re aiming to verify that when code is created or changed it behaves as intended.  We’re also trying to ensure that anything using that code will work properly as long as the unit test is passed.

When writing unit tests there are some key principles that need to be considered:

• Independence - to make sure that one failing unit test doesn’t affect others, you must make sure that each can be run independently


• Consistency - a test should deliver the same results when it is re-run (all other things being equal)


• A single unit of work - it’s important to test small parts (units) of code that have distinct functions


• Good code coverage - the test needs to ensure that all the code is executed, including exceptions


• Run fast - if the test fails the developer needs to know quickly so that it can be addressed

TDD goes hand-in-hand with unit testing.  The concept is that the automated unit test is written before any code - initially the test will fail as the code is not written yet.  Then the minimum amount of code is written in order to pass the test, which can then be refactored as required.

A change in approach to SAP development

In order for unit testing to be effective we need to ensure that the code “units” are sized correctly so they can be effectively tested.  It therefore follows that how code is designed and written needs to change so that applications are built based on these units.

Traditional programming where 100s or 1000s of code lines are written to perform an application function are very hard to test as the code does many things.

This is where object-oriented programming comes in to break down applications into smaller reusable objects and classes.

It helps to follow design principles like SOLID and in particular the concepts of single responsibility and dependency inversion.

• Having single responsibility in your code (i.e. it only does one thing) will improve your ability to inject mock data into the precise and isolated locations where it is needed, and thus enhances the granularity of the objects to be unit tested.


• Dependency invertible code will allow you to easily replace the processing of real data by injecting your mock unit testing data generator object, so that you get predictable test results.

A definition of SOLID can be found here.

It can be a challenging mind shift to adopt this technique but as long as classes are designed and built in the correct way the process should be reasonably straightforward.

Tools like ABAP Unit can then be used to develop and build unit tests.  Ideally, these tests should be executed automatically when code is changed so they can all be verified before being moved anywhere.  Some useful examples on the usage of ABAP Unit can be found here or in SCN here.

 

Conclusions

With the pressure to deliver software both more quickly and safely, the adoption of unit test automation and continuous integration is becoming more relevant.

The end result is improved software quality along with substantial cost savings.  Typically, IT will spend 70-80% of their budget on the development and maintenance of existing systems and on keeping the lights on.  This dwarfs the initial development costs so the extra effort up-front to implement automated unit testing will still deliver significant benefits.

And it means that scarce IT resources can be allocated to work that can deliver more value.

For more information on this subject please download this e-Book here.