Hi, Speaking generally I think this is a good idea for Oak, so I am appreciative of the proposal.
I assume we are talking about enforcement via build automation, meaning there would be a step in the build that would compute the coverage number and fail the build if the coverage number is not met. I believe we'd need the following: - We need to decide on a coverage amount that is the minimum acceptable. I would suggest something in the range of 70%-80%. - We need to be able to achieve the coverage amount without any external dependencies, e.g. no external services. This is necessary so the tests can be run as a part of build automation, or by any developer working on the codebase, without relying on setting up a testing environment that is more involved than simply Java and Maven. This may require some (perhaps considerable) effort to build test tooling or mocks in order to reach the coverage number. - We need a way to provide exceptions, when approved by the group, for specific modules. (The purist in me resists this statement, but the pragmatist in me says I should include it.) There may be a given module for which 68% coverage is about the best that can reasonably be done, or at least it is the best that can reasonably be done for now. This might be as simple as providing an override for the percentage on a per-module basis. We'd need to be careful not to just use this as a way to avoid writing tests however. FWIW I'm trying to chip away at this a little at a time, adding unit tests as an exercise for learning the codebase, so I'm happy to help out here if I can. -MR On Thu, May 11, 2017 at 11:50 PM, Julian Reschke <[email protected]> wrote: > On 2017-05-11 14:03, Angela Schreiber wrote: > >> hi julian >> >> no i didn't, because i don't think it makes sense to enforce a running >> mongoDB for being able to build oak-core. nor does it make sense to me to >> require a coverage that can only be reached with the derby-rdb profile >> enabled. >> > > Stepping back: what's the goal of enabling the checks then? My > understanding was that we don't want to see regressions in coverage going > forward. That's a good goal, but wouldn't work for people developing code > that is only executed when running Mongo or RDB. > > but now that you mention: this is for me another hint that the document >> store implementations should be moved out of oak-core rather sooner thank >> later. i recently looked at it and it seems doable with moderate effort. i >> recently had a discussion with marcel and he proposed that those really >> familiar with the document store code take care of that. >> ... >> > > That's an orthogonal discussion, and yes we should have it. > > Best regards, Julian >
