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

Coverage on ERB #38

Closed
ryanb opened this issue Apr 21, 2011 · 13 comments
Closed

Coverage on ERB #38

ryanb opened this issue Apr 21, 2011 · 13 comments

Comments

@ryanb
Copy link

ryanb commented Apr 21, 2011

Great work on this gem. Is it possible to check code coverage in ERB templates? In a Rails app there might be an "if" condition in a view which is not covered. It would be great if it were somehow possible to check this.

@colszowka
Copy link
Collaborator

No, unfortunately it's not since the underlying Ruby 1.9 Stdlib Coverage library only tracks files that are require'd after coverage starts and thus only allows .rb files (since you can only require files ending with .rb ;)

Templates on the other hand are read from a file and evaluated later on, and thus are out of the visibility of the coverage lib.

Sorry :/

@jamiew
Copy link

jamiew commented Dec 2, 2012

Very old ticket, but do you know if this is possible with any other 1.9 coverage tools?

floehopper added a commit to alphagov/smart-answers that referenced this issue May 14, 2015
This is a "spike" which demonstrates how to obtain test coverage data for
the `additional-commodity-code` flow. This data was not previously
available [1], because the flow files were being read and eval'ed rather than
simply required. The latter is necessary [2] for `SimpleCov` to record coverage
data for the file.

By extracting the existing DSL code into a `define` method on a subclass of
`SmartAnswer::Flow`, we can safely require the file separately from
instantiating the flow. This feels like a better state of affairs in general,
but it specifically addresses the test coverage problem above.

We'd really like to have this coverage data available so we can have confidence
that we're not breaking anything as we continue to refactor the app.

Note that I've intentionally not fixed the indentation in the
`additional-commodity-code` flow file so that it's easier to see my changes.

[1]: https://ci-new.alphagov.co.uk/job/govuk_smart_answers/2396/rcov/
[2]: simplecov-ruby/simplecov#38
floehopper added a commit to alphagov/smart-answers that referenced this issue May 18, 2015
This makes it possible to define smart answer flows as a subclass of
`SmartAnswer::Flow` such that we can obtain test coverage data for the flow
logic.

This data was not previously available [1], because the flow files were being
read and eval'ed (at load time) rather than simply required. The latter is
necessary [2] for `SimpleCov` to record coverage data for the file.

By extracting the existing DSL code into a `define` method on a subclass of
`SmartAnswer::Flow`, we can safely require the file separately from
instantiating the flow. This feels like a better state of affairs in general,
but it specifically addresses the test coverage problem above.

We'd want to have this coverage data available so we can have confidence
that we're not breaking anything as we continue to refactor the app. No flows
have been converted in this commit, it just makes it possible to convert them.
The plan is to convert each flow one at a time in subsequent commits.

I've chosen to suffix the subclass name with the word `Flow`, because I hit
autoloading problems when running **all** the tests, because there are a bunch
of classes in the `SmartAnswer::Calculators` namespace with the same name as
flows.

[1]: https://ci-new.alphagov.co.uk/job/govuk_smart_answers/2396/rcov/
[2]: simplecov-ruby/simplecov#38
@eloyesp
Copy link

eloyesp commented Nov 23, 2017

I know it is an old issue, but it might be possible to add a hook on ERB when it read a template file or it compiles it and add those calls to the result set. Does it makes sense? @colszowka ?

@dmitry
Copy link

dmitry commented Nov 25, 2017

What about HAML / Slim and friends?

@eloyesp
Copy link

eloyesp commented Nov 25, 2017 via email

@ioquatix
Copy link

Any update on using tracepoints?

@eloyesp
Copy link

eloyesp commented Jan 26, 2018 via email

@ioquatix
Copy link

Yeah I tried using trace points and came to the same conclusion. :(

@bf4
Copy link
Collaborator

bf4 commented Jan 28, 2018 via email

@ioquatix
Copy link

I had a look in the MRI source code and for some reason it doesn't compute coverage for eval code which is being parsed.

https://github.com/ruby/ruby/blob/582951e2c8995d6bab5ddaf98cd3816310f8d506/parse.y#L4785

It might just be a matter if being slightly more allowing at that line, i.e. if calling eval with the optional file name argument set to something.

@joevandyk
Copy link

Might this be doable now?

https://bugs.ruby-lang.org/issues/14888
https://bugs.ruby-lang.org/issues/15287
https://github.com/ioquatix/covered/

@ioquatix
Copy link

It works in covered but I don’t use standard coverage library because this bug still applies.

@mame
Copy link
Contributor

mame commented Dec 3, 2022

I have created a PR that will solve this issue: #1037

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

No branches or pull requests

9 participants