>The assertion has been made that typical applications have between 40%-50% of their code actually run during testing.
>
>I am curious to see what percentage of code you test (actually run during development/unit test/system testing) for:
>
>1) The development of a system from scratch.
An advantage of VFP is the level of input validation it offers. InputMask, Format, LostFocus, When and (to some extent Valid) are are very helpful. Most of us typically work from a requirement outline. It may be helpful to approach the project as a series (or glass onion layer) of test and development stages rather than just a completed project. This way, it seems, with the validation tight, all we need to worry about are those process logic errors.

First: There are no such things as USER ERRORS. There are transcription errors, for sure. But nothing a user will do to the system should allow it to crash!

Here are some rules to consider:
1) Never allow a field to have focus, unless the prequesite entries are valid.
2) Never allow a "save" to occur unless the entries are valid and a change has occurred to the entries since last saved.
3) Deliver the project in modules. For example, if you are developing a sales order system, build the inventory maintenance module first - deliver it it for end user testing. While the user is assessing the inventory module, complete the SalesOrder module, integrate with the inventory service, and deliver the SO/IN integration to the user for testing and comment. Then , while thats going on, develop the invoicing and accounts receivable services. Integrate and deliver for testing.
4) Never say bad thing about the legacy system or legacy provider. Be upbeat!

It also helps to have other programmers around that would love to make you eat crow and expose the weaknesses the project may have.Thats expensive. Let the user's staff do that for you. Tell your consumer:
"Try to break it!". Nothing like that stranger test to expose them nasty bugs.

A BIG issue is unreported bugs. Or bugs that the end user suspects resulted from their incorrect use of the system. Eliminate USER ERRORs from your vocabulary. Make the users understand that nothing they do should raise an error!
>
>
>2) The development of a new/replacement system but using code parts (including classes, functions, etc.) from existing and well-running systems.
A little scarry. But if simple and obvious and verifiable - no reason not to!
>
>
>3) Developing revisions to an existing application.
A well planned application anticipates revisions.
>
>
>Thanks for your reply.