PL/1 Unit Tests

We want to unit test PL/1 moduls (also internal procedures).

This would be possible by adding additional code to a module with a generator I wrote. The problem by doing this is that the source code tested would be not the same than the one deployed to production.

To make this possible there should be two things:

1) hook for internal procedure / call / fetch / Exec

What we need would be a compiler option which would allow us to add a custom exit to every marked internal procedure / call / fetch / Exec with or without calling the real end point.

To be able to identify which jump the test is for, the user should set some sort of annotation. For example @test("name")

There sould be only for this points the possibility of testing.

The interface to the exit should be something like

name, commarea, eib ,parms - but I am not sure about what all is needed. The most important is, that we should be able to set all parameters in the exit, so that there is a simmulation of data.

2) Program entrys

The second thing would be the possibility to add a hook to the program entry, because it sould be possible to test internal procedures only.

There again should be an annotation like @testentry("name"). Only possible to be defined on PROC statements.

And now there should be a way to jump to this entry directly (like an assembler goto) without going through the hole code. And here should be a second exit where we could add inputdata.

3) How to test

We have a Pl/1 Code analyser which analyses the hole code down to the variables. The analyser is written in java and runs in rdz/eclipse and the build server.

In eclipse the developper would add the annotations where he wants to test. The analyser works realtime, so the developpers would immediately get the testing points in a sepearate view. As we analyse down to the variables he immediately can add test data to an testing point.

During the build phase which runs on a build server we would aggregate the testdata and deploy it to a mainframe database in xml format.

The build phase also would generate a Test modul for the real modul and call the entrys in the real modul marked with @testentry

After the deployment the buildserver would run a test phase where he executes all testmodules and this would result in running through all test cases.

This would be a perfect and very easy way to have unit tests in PL/1.

Off course the same way could be used to execute integration tests with the database and other sources.