Yes, we use it in QA to ensure that we have tested all major sections
so that we are more confident in sending it to User Acceptance Testing
and then Production. However, we doing use it in production support
and programming too.

Say you have a large processing program with several complex
conditions being required to be met before it will continue. If it
isn't met, it doesn't tell you why. You could:

1) Modify the program to include CRT trace statements to determine
where it bailed

2) Walkthrough it with debugging on.

3) Run it with code coverage and check the report, which will quickly
show you where it bailed.

Obviously, you would prefer the program to have been better in the
first place, but when working with 3000+ programs, most of them circa
1995 or before, you don't always have that luxury. We have used this
method to decent effect in speeding up the time to locate and fix
bugs. Obviously, YMMV and it shouldn't be used as a silver bullet,
just were most effective.

As a final note on the subject, I am unsure of why you would think
being a "UniBasic" programmer should make a difference? Software
development is software development. Being on a U2 system doesn't (and
shouldn't) mean modern practices do not apply.



As to why not just modified jcoverage or the like. Firstly, BDT does
not work for us. We can not actually run or debug via BDT due to
several architectural problems that cannot be solved on our system. We
also could not run any variety that ran directly on the OS for the UD
box either due to a lot of red tape of access privileges and security
policies. This left us with the requirement that it must be coded and
run in native UniBasic, hence this project.

Naturally, other people my be in a different boat from us and this
project may be useless to them. However, maybe it will benefit
somebody else, so here it is.

Horses for Courses, as the saying goes.


Dan


**************

It won't be used by programmers but would by QC/QA types to check and see if
the code is being used or is just a bunch of fluff. One good example would
be if your company is using outsourcing to do your programming and the
outsource is getting paid on the amount of code they produce, instead of the
correct way of getting paid on the quality of their code. You can check to
see if all paths through the code are being used or not.

Jerry Banker

-----Original Message-----
From: u2-users-bounces at listserver.u2ug.org
<http://listserver.u2ug.org/mailman/listinfo/u2-users>
[mailto:u2-users-bounces at listserver.u2ug.org
<http://listserver.u2ug.org/mailman/listinfo/u2-users>] On Behalf Of
Doug
Sent: Friday, November 27, 2009 10:47 AM
To: 'U2 Users List'
Subject: Re: [U2] Code Coverage Project

Dan,

Although I missed code coverage in programming school, I'm not sure how much
UniBasic
programmers would or could use code coverage. That being said, why not take
an existing
program that is fully developed and change the syntax to handle basic
syntax.  This way
you do not have to develop the entire infastracture to run this tool.

My suggestion is there are several open source plug-in for Eclipse that can
be modified
to handle code coverage.  There are several examples like jcoverage or gcov
that could
be used for this type of project.

Regards,
Dougwww.u2logic.com
"Native U2 drivers for PHP"



-----Original Message-----
From: u2-users-bounces at listserver.u2ug.org
<http://listserver.u2ug.org/mailman/listinfo/u2-users>
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to