kezhenxu94@163 <kezhenx...@163.com> 于2020年3月30日周一 下午11:59写道：
> > > > On Mar 30, 2020, at 21:58, Sheng Wu <wu.sheng.841...@gmail.com> wrote: > > > > Sheng Wu <wu.sheng.841...@gmail.com>于2020年3月30日 周一下午9:55写道： > > > >> > >> > >> kezhenxu94@apache <kezhenx...@apache.org>于2020年3月30日 周一下午9:11写道： > >> > >>> In essence, code coverage is a measurement of the code lines that > **have > >>> been executed** during the tests, and the code lines that are executed > in > >>> the tests are **covered** actually, no matter whether they are counted > in > >>> the coverage rate (~26%), my idea is to let the coverage tool > (Cobertura in > >>> our case) **notice** this and count them in the final coverage, and > IIRC, > >>> Jacoco provides an Java agent that does this exactly, I’ll do some > research > >>> on this and forward the conclusion here, or open pull requests > directly if > >>> it works overall. > >> > >> > >> It must be an agent, this is the only case it could measure the lines. > >> If this really could work in this way, should be very interesting. > >> > > > > My concern will be, how to aggregate the coverage across 104 GitHub > > Actions. > > It will be hard to have all result files in one place. > > > > Zhenxu > > WDYT? > > > > That’s not a concern, Codecov is able to merge them automatically > Good to know :) Sheng Wu 吴晟 Twitter, wusheng1108 > > > Sheng > > > > > >> Sheng > >> > >> > >>> > >>> > >>> GitHub @kezhenxu94 > >>> Apache SkyWalking, Apache Dubbo > >>> > >>>> On Mar 30, 2020, at 17:28, Sheng Wu <wush...@apache.org> wrote: > >>>> > >>>> Hi Dev Team. > >>>> > >>>> I am looking at the Coverage dashboard[1] this afternoon. > >>>> 26%+- seems a static status of SkyWalking main repo. Seems not > >>> "good"(for > >>>> normal people). Especially the coverage is caused by > >>> storage/core/receiver, > >>>> less than 15% usually. > >>>> But at the same time, like my twitter description[2], we have > >>> 101(excluded > >>>> 3 CI tasks) e2e and agent plugin tests. These are exact covering > >>>> the storage/core/receiver. > >>>> > >>>> From my understanding, besides these 3 test requirements[3][4][5], the > >>> e2e > >>>> tests exactly are covering storage/core/receiver. > >>>> *Logically, we have a very high coverage rate, which matches my > >>>> feeling (maybe others too)*. > >>>> > >>>> The thing bothering me is, how we should describe this to a new > >>>> contributor? Such as > >>>> 1. What parts of contributions should require UT coverage? > >>>> 2. What e2e should be added? > >>>> 3. Where is the balance and tradeoff between (1) and (2)? > >>>> > >>>> I was trying to add more tests for core module(class > >>>> MetricsStreamProcessor#add), and nearly success yesterday night, but > >>> when I > >>>> was reviewing my own test case, I was asking myself, what are the > >>> points of > >>>> those UTs? I was mocking nearly all dependencies, so the logic is in > the > >>>> tested and untested at the same time. Then I decided to revert and > >>> delete > >>>> those tests. > >>>> > >>>> WDYT? Open my mind to hear more ideas. > >>>> > >>>> [1] https://codecov.io/gh/apache/skywalking > >>>> [2] https://twitter.com/wusheng1108/status/1243798832690782211 > >>>> [3] https://github.com/apache/skywalking/issues/4455 > >>>> [4] https://github.com/apache/skywalking/issues/4530 > >>>> [5] https://github.com/apache/skywalking/issues/4576 > >>>> > >>>> Sheng Wu 吴晟 > >>>> Twitter, wusheng1108 > >>> > >>> > >>> > >>> > >>> -- > >> Sheng Wu 吴晟 > >> > >> Apache SkyWalking > >> Apache Incubator > >> Apache ShardingSphere, ECharts, DolphinScheduler podlings > >> Zipkin > >> Twitter, wusheng1108 > >> > > -- > > Sheng Wu 吴晟 > > > > Apache SkyWalking > > Apache Incubator > > Apache ShardingSphere, ECharts, DolphinScheduler podlings > > Zipkin > > Twitter, wusheng1108 > >
