On 6/6/2014 12:39 PM, Aaron Price wrote:
So I am using the default options for RPGUnit and running all tests.
The RPGUNIT program run from the command line returns the following:
Success. 45 test cases, 131 assertions, 0 failure, 0 error.

Using Run Full coverage gives me the results described previously
(i.e. coverage of only one test case proven by running with
ORDER(*REVERSE) and getting entirely different results, and also that
the lines which are identified as not covered are definitely being
executed during the RPGUnit run)

Very peculiar, and not what I'm seeing at all. I wonder if we're using
the same version of RPGUnit? I have 1.7.2 - taken from

Using append to previous result just appends the last run onto the
previous, meaning I will have to run code coverage 45 times with
different TSTPRC parameters to determine the full code coverage of the
Unit test program which seems excessive, especially as this program is
quite small (500 lines) the unit tests for larger functions could be a
lot longer!

I now understand what you meant in your earlier post. Your situation
seems to be covering exactly one test no matter how many are physically
executing via TSTPRC(*ALL).

In my opinion, the code coverage tool should amalgamate the statistics
for all runs of the analysed program called during the batch execution,
into a single report.

My RPGUnit test /is/ just one execution. Apparently yours is doing
something different, but I can't imagine what that is. RUCALLTST
eventually calls runTests out of CMDRUN, and inside a DOW loop, executes
the tests by calling runTest out of RUN. That executes the test via
callProcByPtr out of CALLPROC and all that does is to call the test
procedure via a procedure pointer. This /should/ be one execution of a
program (RUCMDRUN) making 45 separate subprocedure calls within the
service program TSB.GETCLR and so there shouldn't be any question of the
CC analysis clearing out the results from an 'earlier' run - there isn't
any earlier run!

I genuinely dont see the code coverage tool being useful otherwise,
apart from verifying that certain parts of code are being executed when
using certain parameters, this can be done easily in debug.

I definitely agree with this. Mine behaves the way we'd like it to. If
you like, we can take this offline and try to work out why yours behaves
differently. Either that or create a PMR with IBM, but I'd be happy to
try to suss out what's happening, whether it turns out to be RDi or
RPGUnit I'd like to understand the scenario and get it cleared up.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.