Hi John,

>What is ASSERT function used for?

In every piece of code you make certain assumptions. You assume that a variable has a certain type, you assume that an array exist, you assume that a certain library is loaded, that an object exists, that certain code parts are executed in a cvertain order, that a variable can only have values of a defined range, and much more.

ASSERT is used to verify this assumptions in your program. When you use something like ASSERT TYPE("tcParameter")=="C", VFP presents you a dialog if this is not the case. But only when a) SET ASSERT is ON (the default is OFF) and b) you are running the application in the development environment. Assertions are a testing only tool and should not be used to verify conditions that depend on the runtime state or as a replacement for error handling.

Why are assertions so important, although they are so simple? There are numerous reasons:

a) They document the code. If anyone else or you look at the code later, you know exactly which conditions must be fullfilled for the code to work properly, just by looking at the ASSERT lines. And even if you later call a function passing invalid parameters, upon the first test, you are pointed to the problem.

b) They force you to think about all the assumptions you make. VFP is very flexible, but this flexiblity has drawbacks. In many cases we assume certain environment settings and limits. A simple example. Suppose myUpper() is a function that returns the upper case string of the parameter. Some code might now look like this (it checks whether tcVar is an all upper case string):

IF myUpper(lcVar) = lcVar

what assumption do you make here? Before you read on, think about it? What can make this single line fail? Most people will say, nothing, it will always work. Wrong!

In fact, you assume quite a bit:

- You assume that SET COLLATE is "MACHINE", or in other words that "a" # "A".
- You assume that UDFPARMS is set to VALUE, because passing tcVar to reference might alter the contents of tcVar. In other words, you assume that tcVar will not change when you call myUpper.
- You assume that lcVar contains a string, and not any other data type.
- You assume that lcVar is not .NULL., because this test would fail immediately.
- You assume that the currently selected table doesn't contain a field named lcVar, because then VFP would use the field instead of a memory variable.
- You assume that lcVar exists.

I'm not saying that you should test for every of these assumptions, but you must realize what assumptions you make and then decide how probably they are.

c) Assertions don't hide bugs. Many VFP developer tend to write defensive code, for example they accept almost any input for a function and use default values, if the wrong parameter was passed. Or the check whether a library is loaded and load it, if it's not loaded. Or the check whether a table is open, and if not, open it. All of these samples are examples for defensive programming, and all of them hide bugs.

The question is not: "Is the table open?", but "Why is the table no open even though the function requires it?". And the answer to this questions is usually, because someone else forgot to open it in the first place. In other words, because some code far, far away from this function contains some bugs. Maybe it tried to open it, but failed to do so, who know what kind of bugs this can cause, too.

I'm not saying that defensive programing is bad, it's actually neccessary for shipping stable applications, but everytime you code defensive, you should insert an assertion, and if this assertion comes up during testing, don't ignore it, fix the bug!

Well, there are more reasons, but that's a starting point. :)

>Why should we test in a second instance of VFP? How to do so?

Because its much easier and productive. Most applications I've seen try all kind of strange stuff, just to save the current state of the environment and restore it when the application ended, because they want to do two things at once, preserve their development environment and test their applications. That doesn't work, and most of us have had to enter something like CLEAR ALL, CLOSE ALL, RELASE ALL during testing and then have to load the project again, establish the tools, and so on.

If you test in a second instance of VFP, you can safely leave the environment just as i is, or maybe issue CLEAR ALL, CLOSE ALL, RELEASE ALL at the beginning of your application. You don't have to fear that some debugging tool interferes with your application, for example the timer of SuperCls, or the ON KEY LABELs of CEE. And if this instance crashes, fine, just start a new one. No damaged class libraries, no broken project file, nothing.

And additonally, if you test the APP in a second instance, you can fix the bugs in the class libraries while you test the application. No need to find one bug, cancel, fix the bug, recompile and start testing again. Simply find bug, fix bug, find bug, fix bug, and so on. When you found all bugs, and most bugs are usually smaller bugs that can be fixed in one line of code, like typos, a missed initialization, a misspelled methodn ame, or such, then you recompile and test again.

To test in a second instance, all you have to do is to open VFP twice. I usually do this with a small program that recompiles the application and then issues RUN VFP6.EXE Bla.App. My test instance also uses a different CONFIG.FPW, one that doesn't launch my startup program and points to a different FOXUSER file, so that I can keep different positions of windows for my testing instance and am not fouled by some settings that were establish via my usual FoxUser file.

I've written some pieces in FoxPro Advisor about this which go a bit more in detail.

Christof