Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Structured report #6

Open
zwilias opened this issue Dec 16, 2017 · 4 comments
Open

Structured report #6

zwilias opened this issue Dec 16, 2017 · 4 comments

Comments

@zwilias
Copy link
Owner

zwilias commented Dec 16, 2017

AS IS: giant blob
TO BE: report per module with index and overview

@mariohuizar
Copy link

+1
It would also be great to make the build fail if it doesnt reach a user defined coverage percentage :)

@zwilias
Copy link
Owner Author

zwilias commented Mar 14, 2018

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.

@mariohuizar
Copy link

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.

@zwilias
Copy link
Owner Author

zwilias commented Mar 14, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants