+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 <adel.atallah(a)xwiki.com>
wrote:
  On Sun, Jul 29, 2018 at 5:56 PM, Vincent Massol
<vincent(a)massol.net>
 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