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

ETA Calculator #267

Open
hugo-vrijswijk opened this issue Sep 26, 2019 · 3 comments
Open

ETA Calculator #267

hugo-vrijswijk opened this issue Sep 26, 2019 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers hacktoberfest Great issues to pick up for Hacktoberfest

Comments

@hugo-vrijswijk
Copy link
Member

See #153.

It'd be great to have some sort of ETA calculation to show users how much longer we estimate the mutation run will take. The PR linked above is a great start and already reviewed a lot, but is outdated as we refactored the reporters since. A new start that copies code from that PR is probably better. It could either be a new reporter, or added to the ConsoleReporter.

Some ideas of mine of what this could include (feel free to add/discuss):

  • Using the median of the last 10 (?) runs as an ETA
  • A time formatted ETA
  • Some sort of progress bar by using a third-party library
@hugo-vrijswijk hugo-vrijswijk added enhancement New feature or request good first issue Good for newcomers hacktoberfest Great issues to pick up for Hacktoberfest labels Sep 26, 2019
@cbrunnkvist
Copy link
Contributor

Since you perform the initial test run, shouldn't it serve as a baseline for duration? Rather than having to wait for N runs until you can have some a median value...

@cbrunnkvist
Copy link
Contributor

On that note: in case the time per run is more than trivial (let's say >10 seconds) and the number of mutants is more than trivial (let's say >10 also for good measure) then we must assume that the console output is probably also full of exceptions and other leaking log messages because at that point the code base is of some size. In these situations tracking the progress becomes unpractical.

How about adding (through a config toggle) a sleep(1s) between Finished mutation run 10/257 (4%) and Starting test-run 11... just as a courtesy to the developer when trying have a change to follow on the console what the current progress is?

@hugo-vrijswijk
Copy link
Member Author

Sorry for the late reply 😅. I quite like the idea of limiting the amount of messages outputted to the user in the scenario you outlined. The console reporter is due for a rework anyway. A configurable setting using something like FS2's .metered might be enough to get something quite nice working

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers hacktoberfest Great issues to pick up for Hacktoberfest
Projects
None yet
Development

No branches or pull requests

2 participants