I watched through Ben’s ‘TDD in Rails’ video, and found it very informative - as well as encouraging that my mentalities in testing aren’t off kilter.
One thing I wasn’t sure about - is when he runs his specs going through his TDD process - You can see that the specs fail for “Rails reasons” - meaning that it fails because he’s missing a controller, controller action, view template, etc. Here’s a screenshot: bit.ly/1bRtoMo
Recently I’ve gone through a similar process. Fresh Rails 4.0.2 app with rspec/capybara - and was going through the same outside-in approach that he describes.
The problem that I’ve had, though, is that I can’t get the specs to fail for those same Rails reasons - they instead fail because missing markup on the view template (which, makes sense because if the controller doesn’t exist - there’s no action to render the view that has the markup, etc).
I’ve watched the video over, and can’t find anything special that he did to output those errors, nor could I find anything on stack overflow that wouldn’t require me to monkey patch something.
Unfortunately, setting that flag in the config/environments/test.rb did not change the error that’s being output.
What’s odd, is that last week - while building a Rails engine - I was able to TDD it the same way that you do in your video. However, with this app I can’t. In fact, the past few vanilla Rails apps that I’ve worked on using capybara/rspec, they’ve failed to show the Rails type errors.
Fresh Rails app - added capybara/rspec to the spec_helper file, added a test under features/ and I can’t get seem to get those errors to show up
I had grouped the better_errors gem into bothdevelopment and test in my Gemfile.
As such, better_errors was intercepting.
What’s interesting, is that if you try to use better_errors while running in test mode: rails s -e test, it doesn’t work, and you get errors directly from the server…
Anyways, my apologies to both of you for wasting your time!
Thanks again for taking a moment to help!
By the way, one good way to debug stuff like this is with good old-fashioned puts.
I like to do puts page.body right before the line where it blows up. In this case, you would have seen that better_errors was capturing things pretty much right away.
Great advice! Will most definitely remember that for next time
BTW - thanks for taking the time to chat with Bryana here at gSchool. It means a lot when other developers give of themselves to invest into us students!
I ran into the same issue, but with the “web-console” gem being included in both environments. Removing it from the test group fixed it. Thanks for pointing me in the right direction!