Issue #19857 has been updated by matthew-puku (Matthew Puku). ioquatix (Samuel Williams) wrote in #note-18:
I think "coverage for eval" feature was a good idea for measuring the coverage of Rails view code, but I would like to design it to the minimum necessary for that purpose. Currently, I think it is too flexible than I expected.
Actually, this bug report affects that use case too - if the same view is loaded multiple times (as demonstrated) in different tests, the coverage will not be reported correctly.
We've been running into this issue with system specs. System specs boot a child rails server, which loads the views again and clobbers coverage results from other types of spec. Our workaround is to enforce ~99.5% branch coverage, instead of 100%. It's not ideal. Having said that, our use case is probably niche. There are probably not many folks chasing 100% coverage of Rails views. ---------------------------------------- Bug #19857: Eval coverage is reset after each `eval`. https://bugs.ruby-lang.org/issues/19857#change-114231 * Author: ioquatix (Samuel Williams) * Status: Rejected * Assignee: ioquatix (Samuel Williams) ---------------------------------------- It seems like `eval` based coverage is reset every time eval is invoked. ```ruby #!/usr/bin/env ruby require 'coverage' def measure(flag) c = Class.new c.class_eval(<<~RUBY, "foo.rb", 1) def foo(flag) if flag puts "foo" else puts "bar" end end RUBY return c.new.foo(flag) end Coverage.start(lines: true, eval: true) # Depending on the order of these two operations, different coverage is calculated, because the evaluation of the code is considered different, even if the content/path is the same. measure(false) measure(true) p Coverage.result ``` Further investigation is required. -- https://bugs.ruby-lang.org/