Open zwilias opened 6 years ago
+1 It would also be great to make the build fail if it doesnt reach a user defined coverage percentage :)
As mentioned in the introductory text of the docs, condensing coverage information into a single (mostly meaningless) metric is something I'd very much like to avoid with this project. There may be a case to be made for change-over-time, but even that is tricky: not all code should (or even can) be covered.
An example of code that should never reach 100% coverage:
-- Impossible to instantiate, since you need a value
-- of type `Never` to instantiate a value of type `Never`
type Never = Never Never
-- Unbounded recursion allows us to turn an impossible
-- value into any other type. Since it can't be constructed
-- this can never be called and all is well.
never : Never -> a
never (Never n) =
never n
perform : (a -> msg) -> Task Never a -> Cmd msg
perform tagger task =
Task.attempt
(\res ->
case res of
Ok v ->
tagger v
Err e ->
-- That task can `Never` fail so this branch
-- should `never` be executed
never e
)
task
And yet, that code type-checks, is semantically correct, and pretty much how it works in elm-lang/core
as well.
I see your point. But there should be at least a minimum percentage value that you would like to be met. Or some kind of alarm that you would like to trigger. Like say, look this code has complexity X, and is not tested, bahm! The Jenkins build will not let that go through.
I disagree that that should be a feature of elm-coverage
. That said, the tool can spit out JSON (schema), which further tooling could pick up to do such things with. codecov.io also supports that format, so integration with GitHub (with coverage deltas and whatnot) is also supported.
Either way, I should try to set some time apart to work on elm-coverage
in the coming weeks - it's been neglected a little.
AS IS: giant blob TO BE: report per module with index and overview