This gem is fantastic, thank you! ❤️ about retest

[mattbrictson]

@AlexB52 FYI I found a bug in my alias and fixed it in my original comment. For Rails app the proper script is:

bin/rails test <test>

This is incorrect:

bin/rails test TEST=<test>

[mattbrictson]

Hi @AlexB52 I have been a bit swamped this week but I hope to circle back to this at some point. Sorry!

[mattbrictson]

I will create an issue to investigate bin/rails & bin/rspec instead of bundle exec.

Cool, thanks!

If you want to give the diff command a try it is available on a pre release gem install retest --pre

The projects I work on right now are small enough that I can run the entire test suite in under a minute, so I probably am not the target audience for the --diff feature. That said, I tried it out and it seems to work as advertised. It is a little strange that it runs each test as a separate command, rather than all at once, but I understand why that is happening behind the scenes. Take my feedback with a grain of salt, because like I said, this is probably not a feature I will use very much.

[AlexB52]

Thanks a lot @mattbrictson for taking the time to write this issue. Feels good to know someone else finds retest useful. I really appreciate it

[AlexB52]

@mattbrictson Your alias is great. Maybe I could try to infer the type of Ruby project and its command like you do with your alias 👍

I'll think about it, I want to keep retest as simple as possible while still being flexible and accomodate most or all the cases

[mattbrictson]

Maybe retest -a or retest --auto could automatically detect the project type? It could be an experimental feature at first to get feedback without changing the existing retest experience.

[AlexB52]

That is an excellent idea. I'll introduce an experimental --auto option once I cover all the Ruby setups properly 👍

[AlexB52]

@mattbrictson I know it has been a while and maybe you aren't using retest anymore but just to let you know that I have finally introduced the --auto flag in version 0.9.0: https://github.com/AlexB52/retest/releases

I would love to hear feedback on whether you still use retest or not, the reasons why and what could be improved if you have time.

The last feature before the v1 release is to provide a way to only run relevant specs from a branch diff as a quick check before creating a PR and triggering the whole CI run. #44

Would that be useful? Let me know what you think. Otherwise no worries I understand :)

[mattbrictson]

@AlexB52 the --auto behavior is fantastic! Works mostly as expected (see below). I still use retest via a bash function, but with --auto I don't need that function anymore. Nice.

The one thing about --auto that doesn't match my particular use case is this one:

Setup identified: [RAILS]. Using command: 'bundle exec rails test <test>'

For Rails, I would expect that to be:

bin/rails test <test>

For me bin/rails is significantly faster than bundle exec rails (0.75s vs 1.25s). That speed makes a big difference when doing TDD.

The last feature before the v1 release is to provide a way to only run relevant specs from a branch diff as a quick check before creating a PR and triggering the whole CI run.

Definitely looking forward to trying this out as well. 👍

[mattbrictson]

Likewise for a Rails+Rspec project I would want to use bin/rspec instead of bundle exec rspec.

[AlexB52]

@mattbrictson thanks for taking the time to answer and give feedback. I will create an issue to investigate bin/rails & bin/rspec instead of bundle exec.

If you want to give the diff command a try it is available on a pre release gem install retest --pre It gives you the ability to do

retest --diff=main
retest --diff=main --rails
retest --diff=main 'bin/rails <test>'

This will identify the diffed files from a branch and run the matching specs. I plan to release the v1 soon when this feature has been tested on enough branches at work.

[AlexB52]

Thanks for your feedback. I completely understand why the whole suite works just fine. I feel really lucky when this is possible on a project. I can't say I worked on codebases where running the whole suite was always possible. Hence the feature to remove some frustrations.