I am wondering how others organize their unit tests for when they have a different version of the software they are testing? For example, let's say I have RPG-XML Suite version 2.2 and am actively writing new features, and changes to existing features, into the code base. I want to have "unit test groups per version" for a lack of a better way to say it. So for RXS v2.2 I want to have one group of unit tests that I can run separately from the RXS v2.3 group of unit tests.
In our current beginning adoption of RPGUnit we are simply storing our unit tests in a source physical file named UT22, and then within there we have source members for the various portions of the software that we want to test.
How are others organizing things?
At the moment we don't have the situation with testing different releases as we are just starting with unit test. The RPGUnit framework has no concept of unit test suites. It only knows how to handle single test cases.
The idea I have was to implement a unit test suite where multiple test cases (unit test service programs) can be defined and grouped. Though the I originally wanted to implement that in the RPG Next Gen Editor and do the handling of the test suites there I may be a good idea if RPGUnit also supported test suites.
The test cases would be stored in an data area (should be enough). The data area would be marked as a test suite (the same as with the unit tests, object attribute = RPGUNIT).
Then we would need a program which would execute the test suite and reports the result back.
Would unit test suites be a solution to your problem?
>Would unit test suites be a solution to your problem?
With just the short description you provided here, I *believe* they would fit the bill.
Another thing to think about, that I believe test suite grouping would address, is the modularization of RPG and how you could have the same set of service programs/modules used in many different software stacks. It would be good to have some form of "orchestration" that described which unit tests were associated with a test suite (which is what I believe you are getting at).
Obviously one of the best ways to control this would be to use library lists (at least in my mind), and have the test suit operate off of a given library list.
So the plans for the next release are set:
- more dynamic output provider for test results (userspace, spooled file, junit xml file(s))
- support for test suites
I got quite excited when I came across RPGunit, having just been introduced Junit. But I found RPGunit a bit hard to control and there didn't seem to be any activity or support (no active forums).
It would be great if RPGunit was actively supported by a community because I'm sure that it has a role to fulfill.
One of the limitations I came across was setting up and then tearing down a set of database records just to run a small test. I didn't want to test the database access only the processing logic. I've seen (although I don't fully understand how it works) Java injection. This allows Java programmers to test some functionality without having to set up full connection to ODBC server. Something similar in RPG where a CHAIN just returns a set of values, without going to a database file would be great - I don't know if that's something that can be done with RPGunit?
There was no activity in the forums because no one has posted a question. I also think the concept of unit testing is to "modern" for most RPG developers because unit testing requires modules/procedures to test (which require ILE skills …).
Database setup: I had the same "problem". My solution was to build a fix database in a separate library. The data in the library doesn't change so the results from the unit tests are reproducable.