On Wednesday, August 30, 2017 at 12:31:22 AM UTC+1, Evgeny Mandrikov wrote:
>
> No code in class is executed by test3 and so 0 is a correct value, not 3.
>
Coverage of test3 is only 0 because test cases test1 and test3 are executed
on the
same JVM. However, when test cases are executed in isolation (i.e., one JVM
per
test) both test cases cover 3 lines.
And since no code is executed, then how it can fail? Something is missing
> in your example/explanation.
>
Lets change for a moment the following assertion
assertEquals("SsS", PublicStaticFields.s);
of test3 to something like
assertEquals("fooBar", PublicStaticFields.s);
Now test3 fails, right? How would we explain that fails and does not cover
anything?
> What is the target of test3? What it should test / catch?
>
Exactly the same as test1, the process of initialisation.
> If target is a process of initialization and state after initialization,
> then you need to isolate this process in this test to guarantee that it
> happens here (note that if something else used class prior to test1, then
> even test1 won't observe initialization),
>
Yes, I totally agree with you. Thing is, there are really bad test suites /
cases out there
that are not coded properly. And I'm just trying to find a common solution
that could be
accurate even for those shit test suites / cases.
> so indeed I don't see any other ways than separate JVM
>
I know maven (by default) forks a new JVM per test class, but I do not know
any option
to fork a new JVM per test case. Are you aware of any?
> or properly coded ClassLoader.
>
How could that be done? Can you please provide me some pointers?
If initialization and its test do not have "ClassLoader leak", then JVM
> and GC will free memory that was used during this process. And as was said
> before - this won't impact memory consumed by JaCoCo. And I suppose time
> spent on instrumentation is negligibly small compared to the rest. You can
> do own benchmarks and compre cases with and without
> instrumentation/coverage - this is an interesting exercise and we'll be
> interested to know results. However as a rough approximation - time to
> instrument rt.jar (20693 classes) of JDK 8u131 on my not so fast machine is
> about 15 seconds (including reading from disk, unpacking from JAR,
> instrumentation, packing to JAR and writing back to disk).
>
20693 classes in just 15 seconds, wow.
--
Best,
Jose
--
You received this message because you are subscribed to the Google Groups
"JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jacoco/6d48ba66-6e8d-4108-a1a4-7a5796bb114a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
