[ruby-talk:444267] [ANN] minitest-bisect 1.7.0 Released

minitest-bisect version 1.7.0 has been released! * home: <https://github.com/seattlerb/minitest-bisect> * rdoc: <http://docs.seattlerb.org/minitest-bisect> Hunting down random test failures can be very very difficult, sometimes impossible, but minitest-bisect makes it easy. minitest-bisect helps you isolate and debug random test failures. If your tests only fail randomly, you can reproduce the error consistently by using `--seed <num>`, but what then? How do you figure out which combination of tests out of hundreds are responsible for the failure? You know which test is failing, but what others are causing it to fail or were helping it succeed in a different order? That's what minitest-bisect does best. Changes: ### 1.7.0 / 2023-07-06 * 1 major enhancement: * Extend bisect_methods to do "inverse" run (eg false positives) via -n=/RE/ argument. * 4 minor enhancements: * Added example_inverse.rb * Collapsed examples from directories to individual files. * Refactor: push command generation from #run down to #bisect_methods. * build_files_cmd no longer calls reset (zero effect change). * 4 bug fixes: * 100% documentation coverage. * Fix server process ID to be a string to match rest of args. * Fix shebang cmd on bin/minitest_bisect. * Print known bad methods with found culprit methods in final run.

Hi Ryan, can you please tell us about, how minitest-bisect can help us On Thu, Jul 6, 2023 at 10:49 PM Ryan Davis via ruby-talk <ruby-talk@ml.ruby-lang.org> wrote:
minitest-bisect version 1.7.0 has been released!
* home: <https://github.com/seattlerb/minitest-bisect> * rdoc: <http://docs.seattlerb.org/minitest-bisect>
Hunting down random test failures can be very very difficult, sometimes impossible, but minitest-bisect makes it easy.
minitest-bisect helps you isolate and debug random test failures.
If your tests only fail randomly, you can reproduce the error consistently by using `--seed <num>`, but what then? How do you figure out which combination of tests out of hundreds are responsible for the failure? You know which test is failing, but what others are causing it to fail or were helping it succeed in a different order? That's what minitest-bisect does best.
Changes:
### 1.7.0 / 2023-07-06
* 1 major enhancement:
* Extend bisect_methods to do "inverse" run (eg false positives) via -n=/RE/ argument.
* 4 minor enhancements:
* Added example_inverse.rb * Collapsed examples from directories to individual files. * Refactor: push command generation from #run down to #bisect_methods. * build_files_cmd no longer calls reset (zero effect change).
* 4 bug fixes:
* 100% documentation coverage. * Fix server process ID to be a string to match rest of args. * Fix shebang cmd on bin/minitest_bisect. * Print known bad methods with found culprit methods in final run. ______________________________________________ ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org ruby-talk info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.org...

On Jul 6, 2023, at 18:00, Eike Dierks via ruby-talk <ruby-talk@ml.ruby-lang.org> wrote:
Hi Ryan,
can you please tell us about, how minitest-bisect can help us
I did:
Hunting down random test failures can be very very difficult, sometimes impossible, but minitest-bisect makes it easy.
minitest-bisect helps you isolate and debug random test failures.
If your tests only fail randomly, you can reproduce the error consistently by using `--seed <num>`, but what then? How do you figure out which combination of tests out of hundreds are responsible for the failure? You know which test is failing, but what others are causing it to fail or were helping it succeed in a different order? That's what minitest-bisect does best.

Ryan, You explained clearly the problem that mintest-bisect is trying to solve ("knowing which test is failing, and the interdependence involved"). But you did not explain *how* it does it. From your description it is unclear what methodology is being used or what output/result of using the library is. Thanks, -- Andy On Sat, Jul 8, 2023 at 5:48 PM Ryan Davis via ruby-talk < ruby-talk@ml.ruby-lang.org> wrote:
On Jul 6, 2023, at 18:00, Eike Dierks via ruby-talk < ruby-talk@ml.ruby-lang.org> wrote:
Hi Ryan,
can you please tell us about, how minitest-bisect can help us
I did:
Hunting down random test failures can be very very difficult, sometimes impossible, but minitest-bisect makes it easy.
minitest-bisect helps you isolate and debug random test failures.
If your tests only fail randomly, you can reproduce the error consistently by using `--seed <num>`, but what then? How do you figure out which combination of tests out of hundreds are responsible for the failure? You know which test is failing, but what others are causing it to fail or were helping it succeed in a different order? That's what minitest-bisect does best.
______________________________________________ ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org ruby-talk info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.org...

On Thu, Jul 6, 2023 at 13:49 Ryan Davis via ruby-talk < ruby-talk@ml.ruby-lang.org> wrote:
minitest-bisect version 1.7.0 has been released!
* home: <https://github.com/seattlerb/minitest-bisect> * rdoc: <http://docs.seattlerb.org/minitest-bisect>
Hunting down random test failures can be very very difficult, sometimes impossible, but minitest-bisect makes it easy.
minitest-bisect helps you isolate and debug random test failures.
If your tests only fail randomly, you can reproduce the error consistently by using `--seed <num>`, but what then? How do you figure out which combination of tests out of hundreds are responsible for the failure? You know which test is failing, but what others are causing it to fail or were helping it succeed in a different order? That's what minitest-bisect does best.
Changes:
### 1.7.0 / 2023-07-06
* 1 major enhancement:
* Extend bisect_methods to do "inverse" run (eg false positives) via -n=/RE/ argument.
* 4 minor enhancements:
* Added example_inverse.rb * Collapsed examples from directories to individual files. * Refactor: push command generation from #run down to #bisect_methods. * build_files_cmd no longer calls reset (zero effect change).
* 4 bug fixes:
* 100% documentation coverage. * Fix server process ID to be a string to match rest of args. * Fix shebang cmd on bin/minitest_bisect. * Print known bad methods with found culprit methods in final run. ______________________________________________ ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org ruby-talk info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.org...
The inverse run option is really cool, zenspider. ~Spaceghost -- ~Johnneylee
participants (4)
-
Andy Nutter-Upham
-
Eike Dierks
-
Johnneylee Jack Rollins
-
Ryan Davis