Fix unit tests

[msteiger]

Currently, 38 out of 40 tests fail with

java.lang.RuntimeException: Failed to find natives from .jar launch
at org.terasology.engine.paths.PathManager.<init>(PathManager.java:70)
at org.terasology.engine.paths.PathManager.getInstance(PathManager.java:121)
at org.terasology.HeadlessEnvironment.setupPathManager(HeadlessEnvironment.java:218)
at org.terasology.Environment.reset(Environment.java:53)

I suspect that this is related to the config change in build 105.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3478401-fix-unit-tests?utm_campaign=plugin&utm_content=tracker%2F4847892&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F4847892&utm_medium=issues&utm_source=github).

[Cervator]

Most the unit tests fail locally for other reasons IIRC (changes in engine/logic/unit test setup/headless environment/something) - the Jenkins issue is Nanoware/Terasology#71 and separate to the best of my knowledge :)

Expanding the log a little shows the issue - execution starts inside the Gradle cache so our logic fails to find the natives nearby there (they're in the Jenkins workspace)

    codeLocation: /var/lib/jenkins/.gradle/caches/modules-2/files-2.1/org.terasology.engine/engine/0.1.0-SNAPSHOT+1102/9f15a782dac62e26ca9fee1231814d4a41aab8c/engine-0.1.0-SNAPSHOT+1102.jar
    Failed to find the natives dir within 5 levels of /var/lib/jenkins/.gradle/caches/modules-2/files-2.1/org.terasology.engine/engine/0.1.0-SNAPSHOT+1102/9f15a782dac62e26ca9fee1231814d4a41aab8c
    Failed to find the natives dir - unable to launch!
    18:22:25.062 [Test worker] ERROR org.terasology.Environment - Error
    java.lang.RuntimeException: Failed to find natives from .jar launch

I suspect if we just hack-fixed that by dropping a copy of the natives in the Gradle cache most/all of them would still fail for other environment-related reasons. That's the more interesting fix and might be doable locally :)

The Jenkins fix ... maybe a simple way somewhere to use the source or jar inside the Jenkins workspace rather than going digging in the Gradle cache.

[msteiger]

That's interesting. Running Pathfinding tests in my eclipse workspace works fine (with one failure though).

Still, I will PR a fix similar to the one in NameGenerator, so you (@Cervator) can see if it fixes the tests in your local workspace.

One strange issue is that the module scan path in PathManager is incorrect and I can't see why..

[Josharias]

The latest update to sync up with changes to the engine still showed some issues with tests. I had 3 failed tests (ConnectNavGraphChunkTest.test1,ConnectNavGraphChunkTest.test2, PathfinderTest.testStairs).

[Josharias]

Also, the "Failed to find the natives dir" error was resolved on my local copy when I brought in LightAndShadowResource as source as apposed to the jar it had previously gotten that was referencing a engine jar snapshot.

[Cervator]

As in, gradlew fetchModuleLightAndShadowResources fixed it? Any chance the natives had been cleared and that Gradle call retrieved them or activated them somehow? Although I suppose then the game wouldn't work

Also, ah-hah, sneaky ninja, for some reason I only noticed this (probably from reply to an issue I've posted in) so I didn't realize you had actually fixed Pathfinding. Suddenly hearing you talk about the unit tests clued me in :D

Adding this + LightAndShadow back into the lineup then. Amusingly L&S also spawns you way up due to Terasology/Cities#15 so whether you survive or not (quick console skills?) is, ahemn, up in the air :D

[synopia]

So I fixed the real failing test (because a chunk size change). But still, in jenkins it wont work because of the native thing. If anyone has a solution I will be grateful

[Cervator]

Yep it is on a todo list somewhere to fix, just hasn't been super high priority :-)

It shouldn't be too bad, maybe something like detect an environment variable in Gradle that is set by Jenkins, like the active workspace, then use that instead of the default execution origin point (Gradle cache)

[msteiger]

Could it be related to the fact that the Pathfinding build downloads a different version of engine from Artifactory?

[Cervator]

In a way, as having unit test execution begin from the Gradle cache does indicate it is using a jar from Artifactory. Version I think is unrelated to the pathing, though it could cause other issues.

I tried last night to forcibly set the workingDir in Gradle for unit tests but that didn't work. Probably execution does start correctly, but then PathManager goes wonky since it gets used from an engine jar in the Gradle cache

Was thinking about modifying PathManager to recognize that issue when it is being used like this from Jenkins, but maybe the correct fix is telling Gradle somehow to use the local copy of the engine it gets from copying in artifacts in Jenkins. Which probably is the same (or similar, at least) issue that causes the engine src jar to be downloaded in a normal dev workspace in some conditions.

[jdrueckert]

@casals Is this still the case?

[keturn]

there are some current test failures, and I think some of the same conditions still apply, but enough things have changed in gradle and ModuleManager since 2014 that I am going to close this report as stale.