× 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.



On 5/22/2015 11:36 AM, darren@xxxxxxxxx wrote:

Just saw a recent post from Edmund Reinhardt about a Test Optimizer, so I
look at the tutorial, and it talks about Code Coverage, which I thought was
a java only tool, but the tutorial shows some RPG programs. So, me being a
green screen programmer for a business centered around an MRP package, does
Code Coverage mean anything to me?

I am a green-screen-only, RPG / SQL / DDS programmer. No webbly stuff
for me. I really appreciate having Code Coverage.

I did try running a Code Coverage
Report against one of my programs, and I see a list of my sub-procedures
with various Coverage %s, but I don't see what that means to me.

The theoretical use is to make sure that all your code gets touched
during a test run. The practical upshot might be best illustrated with
an example. Say you have an invoicing program and it does some nasty
calculations in order to deal with taxing different items at different
rates in different jurisdictions. There's a pile of SELECT, IF, DO and
even some old stubborn code with left hand indicators. The City of
Duluth passes a regulation creating a new class of taxable items, so the
invoicing program has to be changed. You make the change and now you
want to test it.

Our classical testing scheme would involve hand-loading a couple of
orders into the order entry system that fall under the Duluth rules, run
the invoice program and see how it went. But this is an ugly program,
with a lot of subtle interactions, and you've been burnt before by
making a change that inadvertently messed something else up. So you
load a few more orders that would test some big customers and look at
those invoices too.

But there's always that fear that something got torqued and you'll find
it later, when customers start complaining. Ugh, the worst. Wouldn't
it be nice if you had a test database that allowed you to test each and
every IF, ELSE, SELECT - if there were a way to see that your test run
touched every line of code?

That's what code coverage does for you. It lets you get a quick (and
IMO useless, but the industry likes it) % of lines covered as well as
being able to see which lines did not get touched. A nice feature is
the ability to 'remember' a previous run, so say you have a section of
code for the Western Division but your system specifically segregates
Divisions into separate libraries.

You run Coverage once for Eastern, it flags the chunk of Western code as
'not touched', set 'remember', change data libraries, and then run it
again for Western. Now Coverage says that you touched Eastern and Western.

It's not a guarantee that any of that code is correct, but it sure does
help identifying test cases you might want to add to your test database.
I've even found hunks of code that I can delete because it pertains to
Divisions that no longer exist.


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.