You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been wondering whether your tool could be used to run each test method in isolation rather than each test class, as original proposed...
So, in order to reset classes at test method level (i.e., after the execution of a test method) I made the following change to vmvm:
diff --git a/vmvm-ant-junit-formatter/src/main/java/edu/columbia/cs/psl/vmvm/AntJUnitTestListener.java b/vmvm-ant-junit-formatter/src/main/java/edu/columbia/cs/psl/vmvm/AntJUnitTestListener.java
index d9f4398..208eb19 100644
--- a/vmvm-ant-junit-formatter/src/main/java/edu/columbia/cs/psl/vmvm/AntJUnitTestListener.java+++ b/vmvm-ant-junit-formatter/src/main/java/edu/columbia/cs/psl/vmvm/AntJUnitTestListener.java@@ -15,7 +15,7 @@ public class AntJUnitTestListener implements JUnitResultFormatter {
@Override
public void endTestSuite(JUnitTest arg0) throws BuildException {
- Reinitializer.markAllClassesForReinit();+
}
@Override
@@ -55,6 +55,7 @@ public class AntJUnitTestListener implements JUnitResultFormatter {
@Override
public void endTest(Test arg0) {
// TODO Auto-generated method stub
+ Reinitializer.markAllClassesForReinit();
}
@Override
Then I ran vmvm (with the above change) on a couple of Java projects and I found a particular corner case to which the execution of the resetter at test method level makes a particular test method to unexpectedly fail. Please find below a minimal project example that triggers the unexpected behavior. (For convenience, the same minimal project can be find in here).
Basically, this minimal project has an enum class EnumXY with two values (X and Y), and a parameterized JUnit test class TestEnumXY which should test the == of enum values. When the test class TestEnumXY is executed, it first collects all values required to execute each test method. In this case it collects the values of EnumXY.X and EnumXY.Y. The execution of the test method test checks whether the parameter value is == to any value in the enum class.
On the first execution of the test method test, the value of xy is == to the value of EnumXY.X and therefore the test finishes successfully. Once the first execution of the test method test finishes, vmvm marks EnumXY class to be resetted. On the second execution of the test method test, EnumXY class is resetted (as it has been marked to be and because there is a getstatic call in the test method to the enum class) and unexpectedly else if (this.xy == EnumXY.Y) { is no longer true and a runtime exception is thrown by the else block. The problem in here is that EnumXY.X and EnumXY.Y get new values when EnumXY class is resetted. Thus, on the second execution of the test method test, this.xy (which was initialized with the initial value of EnumXY.Y) is no longer == to the new EnumXY.Y value, which makes total sense, however it is not the expected behavior.
@jon-bell, although this issue report is not a true issue/problem of vmvm (as it has been proposed to run test classes in isolation and not test methods in isolation), I would like to have your opinion on this.
--
Best,
Jose
The text was updated successfully, but these errors were encountered:
This is very tricky. The @parameters are almost acting as an @before, since they are setting up state. This is solved in the normal (non-parameterized) case, since a new instance of the test class will be instantiated for each test method (by JUnit, under the covers).
I can think of only very ugly solutions to this (e.g. when you reset things, first walk the entire heap to find references to the static fields you are blowing away, then correct those references to point to the right thing). This would be easier to pull off using CROCHET instead of VmVm, effectively doing a checkpoint before any tests run, then rolling back to that point. You could change the rollback code to also migrate old references to new ones.
Hi @jon-bell,
I have been wondering whether your tool could be used to run each test method in isolation rather than each test class, as original proposed...
So, in order to reset classes at test method level (i.e., after the execution of a test method) I made the following change to vmvm:
Then I ran vmvm (with the above change) on a couple of Java projects and I found a particular corner case to which the execution of the resetter at test method level makes a particular test method to unexpectedly fail. Please find below a minimal project example that triggers the unexpected behavior. (For convenience, the same minimal project can be find in here).
build.xml
EnumXY.java
TestEnumXY.java
Basically, this minimal project has an enum class
EnumXY
with two values (X
andY
), and a parameterized JUnit test classTestEnumXY
which should test the==
of enum values. When the test classTestEnumXY
is executed, it first collects all values required to execute each test method. In this case it collects the values ofEnumXY.X
andEnumXY.Y
. The execution of the test methodtest
checks whether the parameter value is==
to any value in the enum class.On the first execution of the test method
test
, the value ofxy
is==
to the value ofEnumXY.X
and therefore the test finishes successfully. Once the first execution of the test methodtest
finishes, vmvm marksEnumXY
class to be resetted. On the second execution of the test methodtest
,EnumXY
class is resetted (as it has been marked to be and because there is agetstatic
call in the test method to the enum class) and unexpectedlyelse if (this.xy == EnumXY.Y) {
is no longer true and a runtime exception is thrown by theelse
block. The problem in here is thatEnumXY.X
andEnumXY.Y
get new values whenEnumXY
class is resetted. Thus, on the second execution of the test methodtest
,this.xy
(which was initialized with the initial value ofEnumXY.Y
) is no longer==
to the newEnumXY.Y
value, which makes total sense, however it is not the expected behavior.@jon-bell, although this issue report is not a true issue/problem of vmvm (as it has been proposed to run test classes in isolation and not test methods in isolation), I would like to have your opinion on this.
--
Best,
Jose
The text was updated successfully, but these errors were encountered: