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.
midrange.com
