I have a small issue (regression?) when trying to boostrap latest Fantom (with Env changes in). When trying ./buildpods.fan full I get

TEST FAILED
sys::TestErr: Test failed: "e en" != "e en etc"
  fan.sys.Test.err (Test.java:181)
  fan.sys.Test.fail (Test.java:173)
  fan.sys.Test.verifyEq (Test.java:96)
  fan.sys.Test.verifyEq (Test.java:90)
  testSys::EnvTest.verifyLocale (EnvTest.fan:266)
  testSys::EnvTest.testLocale (EnvTest.fan:216)

which can be reproduced by typing fant testSys. However testSys::EnvTest or testSys::EnvTest.testLocale yield no error.

I also tried to run all previous tests from testSys in a shell loop to detect unintentional dependencies in test setups/teardowns but for i in $ALL_PREVIOUSLY_RUN_TESTS; do echo $i; fant "$i"; done went without an error too.

I can't spot an error in fant but I suspect the bug to appear only when tests are run in a single JVM session, like FS flushes or something similar.

that is sort of weird, could be some file locking issue

are you using a PathEnv setup?

Here's a PathEnv oddness...

If I run fant testSys::EnvTest with a PathEnv set to my working dir, I get a trace:

TEST FAILED
sys::IOErr: Must use trailing slash for dir: file:/C:/dev/working/etc/sys
  fan.sys.LocalFile.<init> (LocalFile.java:128)
  fan.sys.File.make (File.java:27)
  fan.sys.LocalFile.plus (LocalFile.java:212)
  fan.sys.File.plus (File.java:169)
  util::PathEnv.findFile (PathEnv.fan:71)
  fan.sys.List.eachWhile (List.java:575)
  util::PathEnv.findFile (PathEnv.fan:69)
  util::PathEnv.findFile (PathEnv.fan)
  testSys::EnvTest.testFindFile (EnvTest.fan:120)
  java.lang.reflect.Method.invoke (Unknown)
  fan.sys.Method.invoke (Method.java:536)
  fan.sys.Method$MethodFunc.callList (Method.java:188)
  fan.sys.Method.callList (Method.java:147)
  fanx.tools.Fant.runTest (Fant.java:174)
  fanx.tools.Fant.test (Fant.java:94)
  fanx.tools.Fant.test (Fant.java:30)
  fanx.tools.Fant.run (Fant.java:259)
  fanx.tools.Fant.main (Fant.java:295)

but when I re-try with PathEnv turned off, no error. In testFindFile this is where the fail happens:

// directories
verifyEq(Env.cur.findFile(`etc/sys`).isDir, true)
verifyEq(Env.cur.findFile(`etc/sys/`).isDir, true)

so it seems the test is trying to ensure that a "no-trailing-slash" uri can can be used, but PathEnv isn't cooperating.

I wasn't using util::PathEnv. Both FAN_ENV and FAN_ENV_PATH were explicitly unset.

Running ./buildpods.fan compile fails with util::PathEnv but that probably caused by loading core libraries from the working location. I think that is expected.

CreateDir [file:/home/katox/git/fantom/dev/src/testNative/temp-java/]
Exec /usr/lib/jvm/java-6-sun/bin/java -cp /home/katox/git/fantom/dev/lib/java/sys.jar -Dfan.home=/home/katox/git/fantom/repo fanx.tools.Jstub -d /home/katox/git/fantom/dev/src/testNative/temp-java testNative
Java Stub testNative
java.util.zip.ZipException: error in opening zip file  	
  at java.util.zip.ZipFile.open(Native Method)	
ERROR: cannot init Sys.sysPod
fan.sys.Err: sys
  at fan.sys.Err.make(Err.java:78)	
Exception in thread "main" java.lang.ExceptionInInitializerError
  at fan.sys.Pod.readFPod(Pod.java:140)
Caused by: java.lang.RuntimeException: Cannot boot fan: fan.sys.Err: sys
  at fan.sys.Sys.initFail(Sys.java:522)

I found the source of this issue. The key program flow is this:

1  Env.cur.props(typeof.pod,`locale/en.props`, 1ms)
2  f1 := etcDir + `locale/en.props`
3  f1.writeProps(["e":"e en etc", "f":"f en etc"])
4  x := Locale.fromStr("en")
5  verifyLocale(x, "e", "e en etc")

Line 1 caches locale/en.props in Env (props). Then in 2..3 a new version of en.props is properly written to the respective file. That file is only referenced (not used) in 4. The verification in 5 uses Env.cur.locale to construct a locale but because it supplies Duration.maxVal as maxAge a cached version is used and the newly created file is never read.

This wouldn't be a problem if the first line did not actually happen to be in a different test - PodTest, the rest is in EnvTest.

As the caching mechanism makes Env mutable I think we really should reinitialize it before each test to minimize this kind of surprises.

I'd hate to add complicated extra code paths just for self testing.

I wonder why I have never seen this problem.

You are seeing that PodTest runs before EnvTest and loads the cached locale settings?

The Pod tests aren't actually required since they just wrap Env tests anyways.

If you comment out PodTest.testProps will that fix the problem?

I wonder why I have never seen this problem.

No idea how this could work somewhere, I'm scratching my head too. It is perfectly repeatable on my computers. A different order of tests maybe...

You are seeing that PodTest runs before EnvTest and loads the cached locale settings?

Yes. Running code in testProps loads the cache which is used in EnvTest later.

The Pod tests aren't actually required since they just wrap Env tests anyways.

Yes. But it's not the point - what I missed is that mutable Env was shared in a single test session.

If you comment out PodTest.testProps will that fix the problem?

Yes, it fixes the problem.

OK - I pushed a fix