>Hi Denis,
>
>>What do you think would be a good way to be really sure that an application is fully debugged.
>>
>>What are the different steps that should be applied to an application?
>
>Phew, that's a broad question that can hardly be answered with a single message. < s >
>
>First of all, you should read bugs about testing, debugging and writing solid code. For example, "Code Complete", "Writing Solid Code" or "Rapid Development". Then explore the possibilities of VFP tools, like how to use the debugger, ASSERT, DEBUGOUT or preprocessor commands. Make sure you run all code through the debugger before assuming that it is bug-free. being able to compile a project doesn't mean, it's OK, especially not in VFP. Be clear about any assumption you make, and most important:
>
>When you find a bug in your code, ask yourself you could prevent yourself from making this bug ever again. Find ways to let your program automatically detect these bugs. Make sure you put it on a code review check list to explicitely look for this kind of bugs when you do a code review.
>
>It's also useful to follow discussions on a forum like this one. When someone discovers a bug in VFP, or has a problem due to a misunderstanding on how VFP works, look through your code to see whether you have the same problem somewhere in your code.
>
>And of course, document your code. Write test cases that perform typical operations with your classes. You can run these test cases whenever you change something in the class or in the data model. Make sure, you fix bugs where they are created and not somehwere else. That's the typical problem of defensive programming, it work around bugs, but doesn't actually fix them.
>
>And, if you get a bug report and you can't duplicate it with the current version, don't believe that the bugs has gone away. Bugs don't disappear suddenly. We, as developers, but them in and we are the only ones that remove them. If necessary, get some older version of your program and try to duplicate the bug there. If you can, debug the older version and then compare the code with the new version. The bug have indeed by fixed due to other changes, but it can also just be buried deep into the code and didn't come to the surface.
>
>Christof


Thanks for these informations. It is a very good starting point.