I don’t know that this is so much a reminder of “What can be done with rspec-rails” as a note that, “If you do this will rspec-rails, you will also need to undo it.”
Today’s note: If you hack the application routes for a controller test, you have to reload routes.
The original problem
This all came down to a spec that was attempting to test a method in
ApplicationController. In our Rails 3 setup (rspec-core and rspec-rails 3.7.0), the tests only needed a monkey patched
ApplicationController to happen prior to the test:
before do class ApplicationController def dummy_action dummy_method_actually_under_test end end end it 'example do test' do get :dummy_action #etc... # validate dummy_method_actually_under_test did the thing end
In Rails 4 with the same gem versions, we’d end up with the “No route matches…” which could be remedied by redefining the routes.
before do class ApplicationController def dummy_action dummy_method_actually_under_test end end Rails.application.routes.draw do get 'application/dummy_action/:id', to: 'application#dummy_action' end end
Great! The test passes now! (Insert philosophical argument about whether the person writing the test should have tested a method in this way.)
..until you run the rest of the suite, of course. Now *every* subsequent controller test has a “No route matches” issue. (Insert philosophical argument about whether you should be writing controller tests.)
This should serve as a periodic reminder to clean up after your tests, which in this case is:
after do Rails.application.reload_routes! end
Upgrading (partially) for a System PHP 7
I finally got around to upgrading to High Sierra, which has PHP 7 as a system PHP instead of PHP 5.6. As part of that upgrade, my quick hacks of httpd-vhosts.conf for a couple of small projects had disappeared, since bringing up those virtual hosts would bring up the default site.
In the process of restoring these changes, I checked the main
/private/etc/apache2/httpd.conf and noticed that
LoadModule php7_module libexec/apache2/libphp7.so
was commented out. So I uncommented it, much like I seem to recall doing for prior Apache setup.
Problems and Debugging
sudo /usr/sbin/apachectl restart, I was getting a connection refused. I checked for instances of httpd processes running:
ps aux | grep httpd
I found none.
Eventually, I figured out that I could do a -k option on apachectl:
sudo /usr/sbin/apachectl -k restart
httpd not running, trying to start
/usr/sbin/apachectl: line 92: 37326 Segmentation fault $HTTPD "$@"
Searching around on StackOverflow, I found that conflicting PHP versions were potentially the problem. So I commented out the php7 module again, restarted, and loaded a page with
phpinfo(); on it. Sure enough, PHP 5.6 was running.
/private/etc/apache2 for other php module mentions, I found
/private/etc/apache2/other/+php-osx.conf and commented out the following line:
LoadModule php5_module /usr/local/php5/libphp5.so
httpd.conf, I restarted Apache, and magically
phpinfo(); displayed the 7.1.7 PHP version.
- Pigeon Forge field trip as chaperone
- Pinewood Derby
- Double Bridge Run
- Mardi Gras Parade in Pensacola
- New Pergola
- New Patio
- New Piano
- Trip to Louisville to meet Poland team
- New beds
- Mad Violin
- Blueberry Festival
- Wife quit job
- Savannah to OBX
- Sea Catchers
- Dan TDM in Jacksonville
- Palafox Application
- Etsy shop
- Wife got a new job
- Traveled to Clayton, GA to see total eclipse
- Sang with bishop installation choir
- Palafox Market
- Solar install
- Hurricane Irma panic
- Baby Musical accompaniment
- Solar up and running
- Hurricane prep and Tropical Storm hit
- Webelos weekend
- Pow-Wow for Thanksgiving
- RubyConf NOLA
- Blue Angels Homecoming
- New treadmill
- Trip back to Louisville