-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test(MTE): replace IsolatedMTEExtension with JUnit's TestInstance.Lifecycle #5039
Conversation
I decided to go ahead and rip out the The good news is that I don't see anything in @Terasology that actually used The bad news is that JUnit's default test lifecycle is PER_METHOD, the equivalent of our Isolated mode. That effectively switches the mode of all existing MTE tests. What's the impact of that? Primarily test speed. It's also possible that some tests were written to depend on sharing state between test cases. I haven't checked. To address the speed concern, we can look at things like #5024 and #5029. We could also change existing tests to use PER_CLASS lifecycle where appropriate. That's not necessarily a 100% drop-in compatible replacement, as those tests may have been depending on per-class behavior for our engines but per-method behavior for other instance fields. The other incompatible change is that MTE will no longer provide parameter injection for All in all, there might be some tests we need to update, but there aren't that many MTE tests total. I think it'll be an acceptable cost for the incompatible change. |
Of course, the main question here should be: Did it fix the overlapping engines bug? I think so. None of MTE's tests with either PER_CLASS or PER_METHOD lifecycles trigger it any more. I'm not 100% certain, because there are things I don't understand about some of JUnit's ExtensionContext details, but having simplified things seems to be mostly-compatible with our existing tests and less error-prone. |
dd2ea14
to
cac1e55
Compare
cac1e55
to
a43627f
Compare
# Conflicts: # engine-tests/src/main/java/org/terasology/engine/integrationenvironment/jupiter/MTEExtension.java
engine-tests/src/main/java/org/terasology/engine/integrationenvironment/Engines.java engine-tests/src/main/java/org/terasology/engine/integrationenvironment/jupiter/MTEExtension.java
I tested the reproduction patch from this branch in combination with #5041, and I'm glad to say the test is still effective with server ports out of the equation:
That eases some concern I had: while troubleshooting earlier, I had explicit "count how many instances are alive at a time" checking. Knowing it can show up in tests without that additional accounting makes me feel okay about going ahead with this branch as-is. |
...e-tests/src/main/java/org/terasology/engine/integrationenvironment/jupiter/MTEExtension.java
Outdated
Show resolved
Hide resolved
...e-tests/src/main/java/org/terasology/engine/integrationenvironment/jupiter/MTEExtension.java
Outdated
Show resolved
Hide resolved
} | ||
|
||
@Test | ||
@Order(2) | ||
public void thingsStillExistForSecondTest() { | ||
public void thingsDoNotPolluteSecondTest() { | ||
List<EntityRef> entities = Lists.newArrayList(entityManager.getEntitiesWith(DummyComponent.class)); | ||
// There should be one entity, created by the @BeforeAll method |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no longer a @BeforeAll
method, but only the @BeforeEach
.
// There should be one entity, created by the @BeforeAll method | |
// There should be one entity, created by the @BeforeEach method for this one test |
Also needs to be updated in
Line 46 in 1b230c2
// Create some entity to be shared by all the tests. |
and
Line 63 in 1b230c2
// There should be one entity, created by the @BeforeAll method |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other two places also needs updates, couldn't suggest them via the UI...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, and now that I'm having another look at that test class I've discovered I'm confused about how it should go—
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's some disorganization among the tests. Not always clear where to find (or add) a test case with the various combinations of features, and some things seem redundant.
The problem with this class is that I re-labelled it as a "does not share data between tests" thing, but the seenNames
field it's checking in the second part is shared because it's static, so it's not making a lot of sense and it's not real clear what it should do.
One option would be to drop this entire test class and claim it is covered by https://github.com/MovingBlocks/Terasology/blob/1b230c2354a540a54b485d3a333d7627babb8d0a/engine-tests/src/test/java/org/terasology/engine/integrationenvironment/LifecyclePerMethodInjectionTest.java
I think the difference between this test and that one is that this messes with the state of the EntityManager, and the InjectionTest
one only meddles with the Context.
Is that close enough, or is Context too much of a weird special case compared to the other managers?
Co-authored-by: Tobias Nett <skaldarnar@googlemail.com>
I ran MTE tests locally ( Details
I saw test failures for the following modules:
|
I didn't see the The two Not sure what's going on with all these |
I didn't do anything with Behaviors or any of the Pathfinding modules as I'd lost track of the state of how much which ones are working or things we're keeping. |
Gotcha, makes sense^^ |
Added Terasology/Behaviors#107 |
RailsTest passes here 🚂 |
...ava/org/terasology/engine/integrationenvironment/MTEExtensionTestWithPerMethodLifecycle.java
Outdated
Show resolved
Hide resolved
component.name, seenNames.keySet())); | ||
assertThat(component.eventReceived).isTrue(); | ||
assertThat(component.name).isNotNull(); | ||
assertThat(seenNames).isEmpty(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This currently fails, because seenNames
is a static
class member and thus carried over even on PER_METHOD
runs, it seems.
// FIXME: what to assert here does this make sense or should we drop the whole thing | ||
// and say it's covered by LifecyclePerMethodInjectionTest? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure about this either - I definitely want to keep the part of the test chat checks for which entities/how many are registered. Not sure about the part below, but maybe we can keep it for now with this comment to feel less bad when eventually removing it ^^
…vironment/MTEExtensionTestWithPerMethodLifecycle.java
1ff3c70 fixes the test failure in per-method tests, but I can reliably reproduce another test failure locally in a different location:
The tests run into a timeout when waiting for the chunk region future to complete. The failure message is coming from the exception thrown in Line 40 in 3674bbb
Edit: The test failure is also present on |
#5043 should fix the tests, which enables merging this PR. |
This removes the
@IsolatedMTEExtension
variety of MTE test in favor of using JUnit's TestInstance.Lifecycle to manage sharing things between test methods, as proposed in Terasology/ModuleTestingEnvironment#75.This simplifies things and fixes #5038.
The first commit here a43627f contains a test case that reproduced the failure described in #5038.
In practice, this is mostly compatible with existing MTE tests, but they may need some adjustments. For specifics, see #5039 (comment)
Related
How to test
Run MTE tests of modules. Note that the modules must import MTE from
org.terasology.integrationtest
to use this code; check for module PRs linked to #5010.