On Wednesday, August 30, 2017 at 10:07:02 AM UTC+2, José Carlos de Campos
wrote:
>
>
> 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?
>
Code coverage alone will never give you an ultimate answer of why test
fails. Code coverage is a way to observe which code was executed. And once
again - it is correctly reported that no code was executed.
Speaking of why test fails: If target of this test is process of class
initialization, then this test is incorrect as it doesn't test target. Or
simply because assertion in test is incorrect. Or because of bug in
assertions library, etc.
>
>> What is the target of test3? What it should test / catch?
>>
>
> Exactly the same as test1, the process of initialisation.
>
See above.
>
>
>> 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?
>
No.
>
>
>> or properly coded ClassLoader.
>>
>
> How could that be done? Can you please provide me some pointers?
>
There are plenty of materials about ClassLoaders in internet.
>
> 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/6788333f-da0e-4088-a7e9-14eae7f7b29a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
