Unit testing is important but it doesn't eliminate system testing. For
example, if I modify how I calculate dates in a date routine I can test
the snot out of that. It has input and generates output. But system
testing might show you that you're sending in the wrong input. Or, your
new date routine now uses a file to figure out working days but system
testing may show that file gets locked at an inopportune time.
I think IBM has testing labs they can help you develop scripts that will
help do system testing. With simulated 5250, web, etc loads. I think
I've seen it with a bank of machines to generate the load. Use the date
routine for example.
A system test might involve persistence testing from a web app. Does all
the work you do to preload a table into memory, use a named activation
group, etc, all mean nothing for something non persistant?
Or one client banging away doing date conversions while another client
maintains the date table. Does it lock the file? Does the consumer
client see the new values immediately or do they need to "bounce" their
application?
Rob Berendt
As an Amazon Associate we earn from qualifying purchases.
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.