While trying to figure out why some piece of code was running inside the tests
but not in production I needed to figure out which files where actually loaded
at which point in the code. Using a combination of pry
and the LOADED_FEATURES global ie.
Travis CI is great way to get continuous integration into a project.
So just to get started here is a quick walkthrough, through the setup for a
project of mine. Basically it’s a 3 step process:
Setup rake to run the tests
This is easy, and probably already happens anyway! Just to check
My own .travis.yml for
ActiverecordTranslatable looks like this:
So line by line
Set the ruby version to 1.9.3
Setup the database for the tests
Setup a github hook to notify travis about commits
Now to complete the setup setup the hook for travis under the Settings → Service Hooks on Github.
So now quick, learn more checkout TravisCI docs it’s
Ruby 2.0 (2.0.0-p0) is out since yesterday, so we can now all run it.
If you already got rbenv installed, and ruby-build running via homebrew it is as easy as:
$ brew update && brew upgrade ruby-build
$ rbenv install 2.0.0-p0
Wait for it to compile and yay now running ruby 2.0!
Sometimes it comes in handy to render a template from another place than a
controller in Rails. For example using
WickedPdf to generated some pdfs
inside a model comes in quite handy. Normally you need to setup a lot of stuff
for WickedPdf but since everything is already done when calling the build in
render, we can just reuse this.
So to call render from somewhere besides a controller, well we need a
controller and we can just call render from there, what pops out is the
actually rendered template as a string (that’s why we call render_to_string of
course), which we can now ship of to wherever we need it.
UPDATE: As Fladam Orin points out in the comments this falls flat if you use helpers like url_for since the controller lacks a request object. This is a problem which can be solved by using an ActionView and loading the helpers.
Getting started to debug a problem within the rails lib itself it is nice to be
able to just run a single test. Doing this is pretty straight forward, still it
took me some minutes to get the command right since I found a lot of non working
ways online first. So here it is (as an example I run the test_label test in
$ cd actionpack
$ bundle exec ruby -I"lib:test"
test/template/form_helper_test.rb -n test_label
Look at this post as
well for further details about test running in rails.
Most of the time when I create a model with a boolean attribute I don’t actually
use a boolean in the database. A popular example is published on a blog post,
being implemented via setting the publish_date.
This means that in Rails to use form_for you just need to define the accessors
on the model and everything should work, except it doesn’t because the form
returns “0” for false and “1” for true, as strings. A real ActiveRecord model
gets around this by converting the values to boolean before setting. Since it is
tedious to implement time and time again it is easy to just reuse the Rails
Quick and easy!
Having an element like
and trying to check if the class is set to “.some-class”
does not work in capybara. This is due to the fact that #has_css? checks for
the css being available inside the element not on the element itself. But is
it still easy to check it by accessing the attributes hash.
Works just fine.
This is the start of bunch of (hopefully) regular small posts with snippets for ruby and
rails. It’s supposed to be about those little things I keep looking up again and
so back to topic: Making a rails model save fail!
- Add something to the errors in the validation
- Make a before_filter fail (eg. before_create, …)
Return false in a before_filter, will cause the model save to fail