Thanks for your review. Any suggestions would be welcome.

The root of this idea came from the few (very few) examples of xUnit I was able to locate on the web. But, you are right about combining the production code and the test code. It does not have to be that way with FUnit. They can be maintained seperate if that is the way the developer chooses. I, for one, chose to combine the two by placing the test cases at the bottom of the method. I did this mainly for accessibility. As I develope one, I can easly develope the other without having to jump around the IDE windows. But this is just preference, not a rule.

If you wish, email any fixes, work-arounds or design fixes, and will incorperate them in to the next release.

>Hi, Greg.
>
>>I just submitted a new testing program for VFP. FUNit is a Unit Test utility. Unlike other testing utilities, FUnit tests are inside the application being tested. I got the idea from reading about test-driven development. The idea of actually placing the test code inside the methods to be tested made alot of sense. Especially if the code is going to be reused in different projects. If the test code is outside the code being tested, then when we reuse the code in different project we would have to migrate the test code to that project. Non-sense. Why not make the test case a part of the production code.
>
>Nice project! Although I don't understand why you find the test code mixed with the production code better than separate. Other xUnit implementations always have the test code separated. Indeed jUnit, cppUnit and nUnit all run the tests from separate packages/assemblies and execute compiled code, something that is more difficult to do over non-componentized VFP applications.
>
>I don't think that you have to duplicate test code if you have shared components. What you need to do is to have its tests available separatedly and run them every time you want to change some of this shared code. Of course in no way you should duplicate code, whether it is production or test code.
>
>The project is very interesting anyway (I guess I can use it any way or the other). FoxUnit seems to have freezed on time. I did my own patches, but it has some basic design problems, so building another solution could be ok. Something important (as far as I saw fUnit is like this) is to have a test runner engine isolated from the UI, so the test runs can be easily automated in a build process (something I did with FoxUnit but patching it badly).
>
>If I can help, let me know. My only real work with VFP the last years has been around this kind of tools, as I'm consulting with customers developing with VFP and to be able to put them into Agile practice I had to solve many of those gaps. I'm also doing a VFP implementation of FIT that I plan to publish at Google code soon, if yu are interested.
>
>Regards,