+1 It would also be nice to eventually have some kind of reporting UI, similar to jacoco that allows you to drill down towards the affected pages/vm files, preferably ending with some highlighted view of the covered/not covered lines.
Thanks, Eduard On Sun, Jul 29, 2018 at 7:09 PM, Adel Atallah <[email protected]> wrote: > On Sun, Jul 29, 2018 at 5:56 PM, Vincent Massol <[email protected]> > wrote: > > Hi devs, > > > > During XWiki SAS’s hackathon last week, Simon and me worked on > implementing test coverage computation for velocity code and more precisely > to measure the code coverage we get in XWiki XML pages when running our > tests. > > > > The rationale is that we know what’s our java test coverage but we have > no clue about the velocity one. And we have a lot of code in velocity > scripts in wiki pages. Thus we need a strategy for this too if we wish to > increase our global code quality. > > > > So we have currently developed 2 mojos (xar:instrument and > xar:reportCoverage) in the XAR plugin code and created a JIRA issue, see > XCOMMONS-1448. > > > > Here’s the proposal I’d like your opinion on: > > * Finish working on this to stabilize it and commit/push it > > * Apply the same strategy we have with Jacoco for java test coverage, > i.e. introduce a new xar:coverageCheck mojo that will fail the build if we > get a global TPC under the threshold mentioned in the POM > > > > Consequences: > > * It will mean that whenever we add new velocity scripts (especially > when there are branches such as #if) we will need to improve or add XAR > page tests. This can be done in 2 ways: > > ** by writing/improving a functional UI test > > ** by writing/improving a XAR unit test > > * We will find places that have 0% coverage and these will be good > candidates to add tests for > > > > My POV: > > * We should have the minimum # of functional UI tests since they take > very long to execute. We need them but we shouldn’t test the various > branches with them IMO. Only one path. > > * Instead we should focus on have more of XAR unit tests since they > execute fast and are better suited (with mocks) to test the various branches > > * The XAR unit test framework we have is still pretty new and it’s > probably not to easy to write unit tests for wiki pages in some cases, we > will need to work on that as we discover them. I’m happy to help on that. > > > > WDYT? > > > > Personally I’m ok to try it and see what happens. > > > > Thanks > > -Vincent > > +1 >
