-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
Cleaner test application setup #5797
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
Conversation
6f2bf8c
to
7633787
Compare
I introduced a few extra changes here:
|
So we can ask any information about the generated application that we need.
Since it's used for more than generating the application, but also for asking information about it.
I find myself running `rm -rf tmp/rails/rails_52` or whatever and then running `bin/rake setup` to recreate the test application. Now I can do `bin/rake setup:force`.
Otherwise we will accidentally restore coverage files created by the test app creation jobs, and that will cause conflicts.
7633787
to
a0bb67f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks for doing this! ❤️ I'm fine with this as is but did you want this to go in before or after we do a 2.2.0 release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I meant to approve this at first!
It doesn't matter since it's just about the dev environment, but let's merge it! |
Thanks @javierjulio! ❤️ |
No problem, anytime! Thanks for making regular improvements with this. Always appreciated. |
This a some work I made for #5563. The idea was to be able to have a separate Gemfile including
turbolinks
, run tests against it, and be able to write a regression spec for #5563 against that Gemfile. I managed to run tests against a turbolinks-enabled application, but I'm not sure why the bug didn't reproduce there either.The previous setup didn't work for the previously mentioned purpose because the test application folder name was based off the Rails version, not the gemfile name, so the different test applications for each Gemfile would collide if they used the same Rails version. This doesn't happen with the new setup and we could potentially run tests against two different Gemfiles using the same Rails version.
Since I could make having this turbolinks gemfile useful to catch the bug in #5563, this PR is not really necessary, but I guess it makes the setup more generic, so we could merge it in case we need something like this in the future.