-
Notifications
You must be signed in to change notification settings - Fork 13
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
Comments
+1 |
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 |
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. |
I disagree that that should be a feature of Either way, I should try to set some time apart to work on |
AS IS: giant blob
TO BE: report per module with index and overview
The text was updated successfully, but these errors were encountered: