Continuous Integration has been the norm for many software companies for over 10 years now. The debate about whether the approach is sound is largely done and the empirical data is in…. Continuous Integration improves software quality and reduces the cost to create software products.
So why hasn’t it caught on in SAP?
CI may have had an impact on the edges of SAP i.e. Java apps integrating into ECC or HTML5 apps making REST calls into ECC may be covered by unit test automation, but why isn’t the core?
ABAP supports unit testing…. so where’s all the test automation?
Continuous Integration (CI) is a development methodology that requires developers to integrate their code changes into a central repository frequently. Each change is verified by an automated build and unit tests (possibly even automated integration and regression tests).
The goal of CI is to alert developers to breaking changes as early as possible. It’s fast. It’s awesome.
I know that these things don’t exist in SAP, but we can achieve the same sort of results in a slightly different way. In fact in my humble opinion SAP offers a way to deliver software changes faster and safer than the non-SAP world.
Writing Unit Tests will fundamentally change your approach to development.
A unit is the smallest part of an application, and a test is a test! Unit tests demonstrate the behaviour of units. They don’t prove that units work, they increase our confidence that the units work. Units need to be sized appropriately so that we don’t spend the rest of our natural lives writing complex test cases.
Actually it’s even more fundamental than this. When you start to think about how you will test your units at design time I guarantee you that you will change the way that you write code.
This is why the Test Driven Development (TDD) guys and girls say that TDD is a way of designing software. TDD is a methodology for designing software, the test automation bit is a side effect.
I know acronyms in software are often contrived, but….
I like the SOLID acronym, personally I found this very useful when trying to structure my code in a way that makes unit testing less painful The acronym is slightly contrived but the principles behind it are valuable.
If you follow these guidelines your code will become easier to test. Pay particular attention to the S and D!
Continuous Testing
Bear in mind that writing good unit tests is almost as challenging as writing the code itself, if you find your tests are becoming too complicated this probably means that your classes are too complicated (notwithstanding that some things are complicated because they are complicated).
Continuous Integration Servers
The next problem to overcome is how to ensure your tests are run frequently. The challenge for the off the shelf CI servers is that they don’t integrate with SAPs change mechanism elegantly or at all!
The concept of a “Broken Build” doesn’t apply in quite the same way to SAP because we ship micro changes (i.e. small transports).
Micro Changes
Micro changes are the reason why SAP can can deliver changes quickly in a way fully compatible with Agile.
At Basis Technologies we have extended
Conclusions
The rise in prominence of the digital economy is forcing us all to think about we can achieve a high cadence in software delivery, but in a way that does not short change product quality.
Continuous Integration and Unit Testing are foundational components of any shift towards supporting frequent safe releases into production.
I’ve broken down the in’s and out’s of Unit testing in this short webinar recording, which will help you understand the importance it plays in delivering frequent safe releases into production.
