danmayer (Dan Mayer)
- Login: danmayer
- Email: dan@mayerdan.com
- Registered on: 06/15/2014
- Last sign in: 12/26/2018
Issues
| open | closed | Total | |
|---|---|---|---|
| Assigned issues | 0 | 0 | 0 |
| Reported issues | 0 | 0 | 0 |
Activity
12/26/2018
-
05:15 PM Ruby Feature #15022: Oneshot coverage
- This is great thanks @mame, I think this will be a significant performance win when I add support for this into Coverband https://github.com/danmayer/coverband most folks only care if the line is hit on production as you said opposed to ...
03/11/2018
-
- OK, this lead me on a big journey of chasing better benchmarking related to `Coverage` and Coverband, which is my primary use case for `Coverage`. I learned a lot about getting better benchmarking data as well as where the actual time co...
01/15/2018
-
- I am seeing emails from Aaron's comments.
-
- > Pause / Resume just seems like ignoring coverage information for some code.
Yes, the goal would be to ignore it for some code, but with reduced performance costs.
My thought was much of the performance cost was related to tracki...
01/14/2018
-
- Thanks for the reply... So you are right about the calculating the current coverage with `peek_result` and if we want to avoid complexity, it would be fine to drop the reset method and have the user app handle calculating the difference....
-
- I would like to work on closing this out but I believe due to changes in the API expectations since the bug was filed this is likely to not be considered a bug anymore but more likely to be considered to be expanding the feature set. I a...
06/15/2014
-
- I have been having this problem as well.
It seems good that Coverage.result resets the coverage data, but once Coverage.start is called again it seems like it should start building up new coverage from that point on. In the example co...