I did research on the causes of this problem which is caused by the conflict between Jacoco with on-the-fly instrumentation and PowerMock when loading classes.
*The simplest way to use JaCoCo it is — on-the-fly instrumentation with using JaCoCo Java Agent. In this case a class in modified when it is being loaded. You can just run you application with JaCoCo agent and a code coverage is calculated. This way is used by Eclemma and Intellij Idea. But there is a big issue. PowerMock instruments classes also. Javassist is used to modify classes. The main issue is that Javassist reads classes from disk and all JaCoCo changes are disappeared. As result zero code coverage for classes witch are loaded by PowerMock class loader.* ——Code coverage with JaCoCo <https://github.com/powermock/powermock/wiki/Code-coverage-with-JaCoCo> *Detailed analysis* JaCoCo tracks execution with so-called probes. Probes are additional byte code instructions inserted in the original class file which will note when they are executed and report this to the JaCoCo runtime. This process is called instrumentation. In short, Jacoco will modify the class when it is loaded. Jacoco uses class ids to unambiguously identify Java classes. At runtime execution data is sampled for every loaded class and typically stored to *.exec files. At analysis time — for example for report generation — the class ids are used to relate analyzed classes with the execution data. Meanwhile, when performing unit tests, PowerMock will modify the byte code of the tested class according to your mock requirements, which causes the class ids to change. There are different classes are used at runtime and at analysis time, so the data cannot be related to the analyzed classes. As a consequence such classes are reported with 0% coverage. *Solution* I think we can make Jacoco running in offline instrumentation <https://www.eclemma.org/jacoco/trunk/doc/offline.html> to get code converage. This way classes get instrumented by JaCoCo before any runtime modification can take place. Finally, I have tested it with jacoco's offline instrumentation, and I will fix this issue this month. Looking forward to your suggestion! Issue: #5781 <https://github.com/apache/dolphinscheduler/issues/5781> Calvin Kirs <[email protected]> 于2021年7月2日周五 上午11:59写道： > Yes, the reason is explained in [1]. No need to worry if prefortest does > not contain test classes. > > > Best Wishes！ > CalvinKirs, Apache DolphinScheduler PMC > > > On 07/2/2021 11:54，Ruan, Wenjun<[email protected]> wrote： > In my experience, using the @PrepareForTest annotation only causes code > coverage to fail in some cases. > If you want to write test for Demo.java, and you add the Demo.class in > @PrepareForTest, then the jacoco will not count the coverage in Demo. > > Public class Demo{ > } > > @PrepareForTest({Demo.class}) > Public class DemoTest{ > } > > If you add other class in @PrepareForTest, it will not affect the code > coverage in Demo. > > Thanks, > Wenjun Ruan > > From: Calvin Kirs <[email protected]> > Date: Friday, July 2, 2021 at 11:25 AM > To: [email protected] <[email protected]> > Subject: Re: [DISCUSS] About the problem of incorrect unit test coverage > in the API module > External Email > > It would be nice to provide a clear context, otherwise I can only > speculate. > > > 1:It is possible that there is a problem with PowerMock, and there is no > good solution for it. You can refer to [1]. Or avoid using the @Prefortest > annotation. I don't know much about your specific problem, so I can't give > you much help > > > 2:Did you add the relevant test class in the root pom? > > > > > [1] > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpowermock%2Fpowermock%2Fwiki%2FCode-coverage-with-JaCoCo&data=04%7C01%7Cweruan%40ebay.com%7C2dc138b5f6324b0a7d1c08d93d0906b6%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637607931245142561%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sOjfCux9bYxwf9V4CoppnvbwX%2F0S0xI5oHFR%2Fr728RA%3D&reserved=0 > > > Best Wishes！ > CalvinKirs, Apache DolphinScheduler PMC > > > On 07/2/2021 11:16，Yuanhao Ji<[email protected]> wrote： > I’m sorry. Please see: > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fdolphinscheduler%2Fruns%2F2465779491&data=04%7C01%7Cweruan%40ebay.com%7C2dc138b5f6324b0a7d1c08d93d0906b6%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637607931245152554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vVVGdJbtKfMFI3HZH3NsgsI2B%2BcOdwWB2B8nDjM8IR0%3D&reserved=0 > > Hemin Wen <[email protected]>于2021年7月2日 周五10:51写道： > > hello! > > The image in the mail cannot view, can you send detailed error information. > > > -------------------- > Apache DolphinScheduler Commtter > Hemin Wen 温合民 > [email protected] > -------------------- > > > Yuanhao Ji <[email protected]> 于2021年7月1日周四 下午9:50写道： > > Hello, everyone! > > I'm dealing with the problem of *incorrect unit test coverage in the API > module*. > > First, I want to ask if anyone has encountered this problem or have any > suggestions? > > [image: image.png] > > In addition, my thoughts on this problem are as follows: > > 1. First of all, we should find out the cause of this problem. It is > preliminarily speculated that this problem is caused by the > *@PrepareForTest > annotation of Powermock*. > > 2. When the cause of the problem is accurately identified, I'll fix it. > > 3. In addition, I will further write a complete and detailed *document > for the unit test of the API module* to remind developers what problems > should be paid attention to when writing unit test codes. > > Look forward to your suggestions! > > >
