This bug has been fixed, please see: https://github.com/apache/dolphinscheduler/pull/5817. If your workflow fails or the error message contains jacoco-related content, please contact me. Thank you very much.
Calvin Kirs <[email protected]> 于2021年7月10日周六 上午2:08写道： > Very good, in fact, this problem has been troubled for a long time, and I > look forward to your PR submission. > > > Best Wishes！ > CalvinKirs, Apache DolphinScheduler PMC > > > On 07/9/2021 21:07，Yuanhao Ji<[email protected]> wrote： > 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! > > > >
