× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Buck,
Reading your post I think I have just realised what may be happening. Do
you have a teardown routine in the test you are running?
I am 99% sure (I have no AS400 access till Monday to check) that there is
a teardown routine in the one I am running which is closing down the
program/temporary files/overrides etc between each test run. Judging by
this, http://rpgunit.sourceforge.net/cookbook.html#tear-down-close-all it
looks like the teardown routine does execute between each test case.
This may explain why it is only showing the final run of the program... if
it is this though as I would still expect the amalgamated results for the
entire batch job to be shown, sounds like a bug in RDi
Regards
Aaron
-----"WDSCI-L" <wdsci-l-bounces@xxxxxxxxxxxx> wrote: -----
To: wdsci-l@xxxxxxxxxxxx
From: Buck Calabro <kc2hiz@xxxxxxxxx>
Sent by: "WDSCI-L" <wdsci-l-bounces@xxxxxxxxxxxx>
Date: 06/06/2014 06:56PM
Subject: Re: [WDSCI-L] RDi 9.1 Code coverage tool - Main Procedure not
covered

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
RPGUNIT/RPGUNIT1(A_README)

> 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 don.t 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.
--buck
--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [1]http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [2]http://archive.midrange.com/wdsci-l.
</wdsci-l-bounces@xxxxxxxxxxxx></kc2hiz@xxxxxxxxx>

JHC are proud authors of Figaro
This message is private and confidential. If you have received this
message in error, please notify us and remove it from your system.
This message has been scanned for all known viruses. However, recipients
are advised to apply their own antivirus detection measures to this
message and any attachments upon receipt.

JHC Systems Ltd is a company registered in England and Wales. Registered
number: 08729370. Registered office:Temple Point, 1 Temple Row,
Birmingham, B2 5LG, England.

References

Visible links
1. http://lists.midrange.com/mailman/listinfo/wdsci-l
2. http://archive.midrange.com/wdsci-l

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 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.