Conversation
61f3a5c to
0cd1975
Compare
|
I would prefer if we integrate it into https://github.com/crowbar/crowbar/blob/master/Guardfile. Then we have all the guard code at one place. |
but that will not work anymore if you just clone this repo... only works if you set up a development environment with the barclamps folder that has this repo here, which not everybody does. |
| guard :rspec, guard_opts do | ||
| watch('app/controllers/application_controller.rb') { | ||
| "spec/controllers" | ||
| } |
There was a problem hiding this comment.
why do we mention the application_controller here explicitely?
There was a problem hiding this comment.
Because if the application_controller changes, all controllers need to be retested.
|
@rsalevsky I would prefer the opposite, because they have no goals or code in common. |
|
There are two reasons why I think it is better if we do it in the crowbar repo:
If you get another +1 feel free to merge it I don't want to block merging this if it helps making faster progress. |
I agree that's a benefit, but only a very small one which is outweighed by the other considerations below:
This is mixing two completely different things. One is syncing to a remote server, which is useful for testing deployed code, and the other is running unit tests directly from within a development environment. Sometimes you might want to do one, sometimes the other, and sometimes both at the same time. So it doesn't make sense to couple them together. Other reasons:
|
If we do "bundle install --deployment" then gems get installed into vendor/bundle/ which we don't want interfering with git.
We want the :development group to contain gems which are needed for interactive development but not for automated testing. This will allow us to exclude them from CI runs, to speed up the runs, and also work around that the listen gem isn't supported on old Rubies any more.
Guard is indispensable for TDD red/green coding. https://github.com/guard/guard#readme
|
Rebased |
It's indispensable for TDD coding.