Regression testing Regression testing means to compare the results a piece of software is giving before and after changes were made to the source-code.
In my last blog-post i pointed out, that sustainable development meets the customer requirement no unwanted changes of existing behavior. Regression tests are part of sustainable development, because they should fail, if enhancements or refactorings break existing behavior.
Unit-tests can be executed as regression tests.
But before they can be executed, values must be assigned to the input parameters, to the parameters of the test-doubles and to the expected results (test-data).
How to determine the test-data
If the source-code is already covered by unit-tests or mainly free of technical debts, this is quite a simple task. But things getting difficult, if nobody developed unit-tests before, test-data is unknown and the source-code contains high technical debts. In the first approach we can set a breakpoint at the points, where the input parameters, the parameters of the dependencies, which we want to replace with test-doubles, or the actual results are visible. When reaching the breakpoint in the ABAP debugger, a export-function for the values of the input parameters, for the values of the dependency-parameters, or for the values of the actual results would be nice. With this export-function we can use the values as test-data for the unit-tests.
There are actually a few solutions, that provide such an export function. Three of them, i want to present you in this blog post:
1. Export to local files
The table-viewer comes with a built-in function to export table contents as tab-delimited-text-files, as xml files or as spreadsheet-calculation-files.
It's very simple, to create parsers for tab-delimited-text-files and for xml-files and for this reason a lot of solutions are possible. Even for spreadsheet-calculation-files (Microsoft-Excel) solutions like abap2xlsx were implemented.
An approved solution is the mockup-loader project, which can be used to import tab-delimited-text-files or Microsoft-Excel-files.
One disadvantage is the missing connection to the transport-system, when the files are stored in the filesystem.
2. Generate code-snippets with the VALUE-operator Alexander Geppart presented another idea in his blog-post. He implemented ABAP debugger enhancements, which are creating code-snippets, that fill the test-data.
The test-data is then directly placed in the test-class, which can be a pro and a con. It's an advantage for tiny structures and tables. Huge structures and tables causes long and confusing test-methods and then it's a con.
3. Export to ecatt-test-data-containers
This solution is based on the idea, to let debugger-scripts fill ecatt-test-data-containers with the current values of the visible local or global variables. The solution can be found under open-source-license at github.
The main advantage is the possibility to export and import a complete set of variables at one time, the direct connection to the version-control and transport-system.
Last but not least the ecatt-test-data-containers can be simple edited in the SAP-GUI.
Further use-cases for the export functions
One further use-case i see for sensing variables.
Sensing variables were a idea of Micheal Feathers, which he presented in his blog-post and they are useful to preserve existing behavior. Feathers idea was to use unit-tests, that fail in the first step and show the actual values of the sensing variables. Instead of using unit-tests, it would be quite simpler to use the above export functions for value determination of sensing variables.
I hope the export functions presented in this blog-post can help you to manage huge structures or huge internal tables in regression tests. And the end of this blog-post, there is a list with additional reference for those, who aren't familiar with the ABAP debugger: