Bug: FoxUnit does not recompile unit tests

[cwollenhaupt]

VFP adds compiled FXP code to an internal cache when it instantiates a class with either CREATEOBJECT() or NEWOBJECT(). Subsequent instantiations use the cached version. This is still true when the PRG file changed even with sET DEVELOPMENT ON. CLEAR commands are not removing the FXP file from the cache.

This matters in FoxUnit, because switching branches and reverting changes with Git will update any PRG file, but not the FXP file. If tests from the previous branch have been executed, FoxUnit continues to run the previous tests on the new branch until CLEAR ALL/RELEASE ALL is issued or VFP is restarted. The program below demonstrates this.

While it doesn't cover the classes that are tested, at least for the test classes we can make sure they are up-to-date by recompiling any test program that is loaded before running each test.

Set Safety Off
Set Development on
Clear All
Release All
Clear

Local lcCode
Text to m.lcCode noshow
Define Class Test as Custom
	Function GetResult
	Return "Hello"
EndDefine 
EndText 
StrToFile(m.lcCode, "Test.prg")
Compile Test.prg

Local loRef
loRef = NewObject("Test","Test.prg","")
? loRef.GetResult()
loRef = null

Clear Program
Clear Class Test

Text to m.lcCode noshow
Define Class Test as Custom
	Function GetResult
	Return "World"
EndDefine 
EndText 
StrToFile(m.lcCode, "Test.prg")

* uncomment this line for a fix
* Compile Test.prg

Local loRef
loRef = NewObject("Test","Test.prg","")
? loRef.GetResult()
loRef = null

[eselje]

I am amazed that you know that, and also that you would be in a situation that it would be an issue. Do you leave FoxUnit running continuously and have run into this issue? But wouldn't using the best practice of creating the object you're testing in the Setup() method and releasing it at TearDown() resolve this issue? Eric

…

On Wed, Dec 6, 2017 at 4:57 AM, cwollenhaupt ***@***.***> wrote: VFP adds compiled FXP code to an internal cache when it instantiates a class with either CREATEOBJECT() or NEWOBJECT(). Subsequent instantiations use the cached version. This is still true when the PRG file changed even with sET DEVELOPMENT ON. CLEAR commands are not removing the FXP file from the cache. This matters in FoxUnit, because switching branches and reverting changes with Git will update any PRG file, but not the FXP file. If tests from the previous branch have been executed, FoxUnit continues to run the previous tests on the new branch until CLEAR ALL/RELEASE ALL is issued or VFP is restarted. The program below demonstrates this. While it doesn't cover the classes that are tested, at least for the test classes we can make sure they are up-to-date by recompiling any test program that is loaded before running each test. Set Safety Off Set Development on Clear All Release All Clear Local lcCode Text to m.lcCode noshow Define Class Test as Custom Function GetResult Return "Hello" EndDefine EndText StrToFile(m.lcCode, "Test.prg") Compile Test.prg Local loRef loRef = NewObject("Test","Test.prg","") ? loRef.GetResult() loRef = null Clear Program Clear Class Test Text to m.lcCode noshow Define Class Test as Custom Function GetResult Return "World" EndDefine EndText StrToFile(m.lcCode, "Test.prg") * uncomment this line for a fix * Compile Test.prg Local loRef loRef = NewObject("Test","Test.prg","") ? loRef.GetResult() loRef = null — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHy8TJc3OhHt2E7pTYTJOWV5X2H2CIQoks5s9nMXgaJpZM4Q3uYk> .

[cwollenhaupt]

It doesn't really matter where I create the object or the unit test. Once an object is created, VFP will only ever hand you out a copy of this object until you either COMPILE the .prg file or clear everything from memory with CLEAR ALL.

The reason I'm running into this is because we create one branch for every ticket that we are working on. When I'm reviewing a pull request, I switch to that branch and run unit tests to make sure that everything works. So in the course of a review I'm switching branches several times.

Sometimes the issue is that I'm heading down the wrong path. I start by creating or updating a unit test, do some changes, trash all of that by reverting to my clean state and start again. The source code is back to normal now, but unit tests and classes are not.

It's more of an issue that can hit you unexpectedly, though. You might wander why your unit tests keep failing or mistakenly assume their are passing, when you are actually not testing the PRG that you believe you are.