At 05:24 PM 7/13/2015, you wrote:
At 11:15 2015-07-13, Ken Dibble <[email protected]> wrote:
I would just add that it is not necessary to compile a VFP program
to test it. Just run it. If you do that first, you will find out if
your code is working immediately. When you know that, then you can
safely attribute failures in the compiled version to the
compilation process and not to your code.
Plus, it saves time....
Unless you get bit by set development off or some caching or
_____. (If there is not always something else, that is still a
close approximation.)
I almost always compile before testing. When I do not, I do
not count it as sufficient to release the code.
I prefer to reset my environment when I start testing. That
includes a fresh compile.
Many years ago, I had a program that was not working
right. Over a period of about two hours, I finally narrowed the
error down to one page of code. When I examined that code, I saw
that there was no way that it could causing the error. I refreshed
my environment, and the "bug" was gone. I still do not know what
happened, but suspect that a previous try of the code corrupted
something that I was counting on.
Actually, I was trying to save time in explaining how to save time:
Running isolated segments of code in the IDE is the first line of
defense. It catches almost all errors. So I do that first.
My framework has a "test mode" for scx forms that will set up the
full application environment for me when I "run" a form, so I don't
have to go through the whole process of starting the application,
logging in, etc., before I get to what I'm trying to test.
I always shut down and restart the IDE before testing anything.
When I'm pretty sure I have isolated segments of code working
properly, then I run the full application, again restarting the IDE each time.
Last step is to compile the code. The compile may catch a few silly
syntax errors that are easy to find and fix.
Finally, I test the compiled .exe. At this stage, I sometimes find a
few errors along the lines of behavior differences between different
versions of objects that were in the IDE's path and those that were
actually compiled into the .exe.
All of these steps potentially catch bugs. The earliest steps catch
the most bugs, and if you do them in the order described, you can
build confidence in portions of the code and narrow down issues to
smaller fields of inquiry, all the while optimizing one's use of one's time.
And yup, there are still always little quirks. Did I ever tell ya the
one about VFP 6, where I could reliably make the IDE crash by closing
a running scx form by clicking its "close" button with the mouse
positioned half over the button and half over the IDE window
background? Crashed it every...single... time.
Ken
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/8B.20.15846.72554A55@cdptpa-oedge01
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
