• Controllers are models, too;
• Controller specs can be written and ran more quickly than integration tests;
• (My own reason #1) It’s very easy to write them using the basic scaffholding provided;
• (My own reason #2) If they are not easy to write, it’s because you are doing some nasty complex not-that-CRUDdy stuff. Uh oh. Which is what was happening in my case.

But mainly, I don’t see tests as testing instruments per se. I see tests as a way to reflect on your code, see how complex it is, and an opportunity for refactoring as well.

That being said… What I did was to pick up the scaffholding and adapt it as needed, and here is the trouble that I ran into when testing controllers.

First, run the scaffholding routing tests. Yeah, just go ahead and do it. And now correct them to account for all the nested resource paths that you have, as well as the paths that you don’t want to allow. You are going to need it.

Now open your scaffholding controller tests. Each example refers to a single method of the controller, and you have tests for each action that the method must take. If you run them and they don’t behave as expected, there can be several reasons, but from my (very limited experience), here are the most common:

1. you didn’t set your valid_attributes properly – including having nested attributes that are required and are not being set;
2. you are using authentication and need a current_user (modifying valid_session);
3. you have nested resources and so need to set the id(s) of the parent resource(s).

Let’s go through each of these in order…

Attributes

First and foremost, have you tested your factories in your models? Good.

What I usually do is to make use of the FactoryGirl attributes_for method and just stick it in valid_attributes:

def valid_attributes
  FactoryGirl.attributes_for(:my_model)
end

However, this won’t work when you have validates_presence_of for a has_one association. Say that my model has:

    has_one :banana
    validates_presence_of :banana
    accepts_nested_attributes_for :banana

Then, even if you have the association with the banana model in your “my_model” Factory, you’ll get an error because attributes_for does not include associations and thus banana is not there. To fix that, we do:

def valid_attributes
    banana_attribs = FactoryGirl.attributes_for(:banana)
  FactoryGirl.attributes_for(:my_model).merge({:banana_attributes => banana_attribs})
end

Finally… if your model belongs_to another model, let’s say that it looks like this (can you tell I’m hungry?):

    has_one :banana
    validates_presence_of :banana
    accepts_nested_attributes_for :banana
    belongs_to :strawberry

Assuming that you set up this association correctly in FactoryGirl, you’ll have a strawberry_id in your model’s attributes. You have two options: either to set it up as an attr_accessible, or to get rid of it in the valid_attributes in order not to get a security error:

def valid_attributes
    banana_attribs = FactoryGirl.attributes_for(:banana)
  FactoryGirl.attributes_for(:my_model).except(:strawberry_id).merge({:banana_attributes => banana_attribs})
end

Disclaimer: I was going to write a method go go through all the associations and do this automagically, but then I figured that it was kind of cheating because it is really valuable, like I said, to reflect on the way that you are writing your code. At least for me, it is.

Authentication and authorization – you need valid session data and a current_user variable

If you are using any kind of authentication, you need to set up a valid current user and a valid session. Here’s how to do it if you are using Devise:

before(:each) do
  @request.env["devise.mapping"] = Devise.mappings[:user]
  user = FactoryGirl.create(:user)
  user.add_role(:master_of_all_fruits) # don't forget that if you are doing authorization, you need to set up the correct role as well
    user.confirm! # or set a confirmed_at inside the factory. Only necessary if you are using the confirmable module
  sign_in user
end

it "should have a current_user" do
  subject.current_user.should_not be_nil
end

Also, don’t forget to set up the session:

def valid_session
  {"warden.user.user.key" => session["warden.user.user.key"]}
end

The errors that are given are not clear at all in this case, so make sure to check that you didn’t forget to set up the valid session and the current_user!

Nested resources

If my_model is a nested resource, you need to adapt your controller spec in order to account for that. Suppose that we have

resources :strawberries do
  resources :my_model do

When you run the scaffholding for my_model controller tests, you’ll get a “No route matches…” followed by a hash of my_model.

So what you have to do is to: * add the strawberry_id to the actions that require a /strawberries/:strawberry_id/my_model route; * add the @strawberry to the redirects that require the same type of routes.

What I do is to use a before(:each) that creates the required @strawberry:

before(:each) do
    @strawberry = FactoryGirl.create(:strawberry)
  end

it "redirects to the created my_model" do
post :create, {:strawberry_id => @strawberry.id, :my_model => valid_attributes}, valid_session
response.should redirect_to([@strawberry, MyModel.last])
end

it "redirects to the my_models list" do
  my_model = MyModel.create! valid_attributes
  delete :destroy, {:strawberry_id => @strawberry.id, :id => my_model.to_param}, valid_session
  response.should redirect_to(strawberry_my_models_url(@strawberry))
end

# Don't forget to create my_models for @strawberry in the nested route!
describe "GET index" do
  it "assigns all my_models as @my_models" do
    my_model = MyModel.create! valid_attributes
    @strawberry.my_models << my_model
    get :index, {:strawberry_id => @strawberry.id}, valid_session
    assigns(:my_models).should eq([my_model])
  end
end

What if you also have a route like this:

 resources :my_models, :only => [:index, :show]

What I do is that I divide the tests into two contexts:

 context "directly via /my_models" do
  #...
end

context "via /strawberries/:strawberry_id/my_models" do
  #...
end

and place the “before(:each)” that creates @strawberry in the nested route context.

Conclusion

I managed to detect many bugs in my controllers doing this (especially variables that I had assumed not to be nil and that were not set). Testing controllers is easy and fast, so I strongly advise you to test your controllers!

Eventually, I’ll also do a post on integration testing with rspec, but for now, here’s another resource from Everyday Rails that covers the topic very nicely. Enjoy!

Martin Fowler, the father of software patterns, has an amazing introduction to nosql (or, rather, “polyglot persistence”) which should remind us of why we have nosql systems: to facilitate horizontal scaling. That means that so many startups that are using nosql just because it’s fashionable should probably just use a traditional sql model and follow the “Premature optimization is the root of all evil” motto by Knuth.

And now jumping from backend to frontend, he also has another amazing overview of developing software for multiple mobile devices. The most obvious downside to writing multiple native apps is the cost of building several copies of the same application and then, especially, maintaining them. In my case, I started learning iOS programming some time ago, but didn’t pursue it actively at the time, and am now wondering whether learning multiple platforms is a good idea, or whether I should go with a cross-platform toolkit. The overview has a list of the problems of going down that road. The solution is again… mobile web apps:

“Don’t try to make a web app work like a native app. This is the path to the Uncanny Valley. Instead focus on making it a usable web app, building on the familiarity of how the web works on devices.”

In the end, the slideshow provides a nice algorithmic way to determine whether you should go the native route, the mobile web app route, or something in between, depending on whether the app is part of your core product or just a side channel to reach more customers. Highly recommended!

FactoryGirl and Polymorphic named associations

If you have polymorphic associations with different names, here’s how to go about it in factories:

 factory :category, aliases: [:category_one, :category_two] 

There are other approaches to this problem here, but I find this one to be the simplest and so far it hasn’t gotten me into trouble (perhaps yet :-) ).

Attributes_for

This is probably very obvious, but I find it useful to use attributes_for from FactoryGirl to build the valid attributes for use in controller specs.

 def valid_attributes
    FactoryGirl.attributes_for(:my_model)
    end

One thing that is useful to know is that attributes_for ignores associations, and thus does not include attributes that are related to associations even if you have an association in the factory. Here is a post at stackoverflow that provides you with the foreign keys in the attributes if you need them.

Has_and_belongs_to_many associations

I’m just adding this for my own reference. It’s in the FactoryGirl getting started wiki.

 FactoryGirl.define do
  factory :person do
    first_name { 'James' }
    books {
      Array(5..10).sample.times.map do
        FactoryGirl.create(:book) # optionally add traits: FactoryGirl.create(:book, :book_description)
      end
    }
  end
end

There is more in FactoryGirl associations here.

DRYing up: Traits

I just discovered traits, which are ways to add state to a factory (read: create factories whose attributes have different values without having to go through aliases). I am shamelessly copying Thoughtbot’s example because I think it’s the clearest one to have here for your reference:

 FactoryGirl.define do
  factory :todo_item do
    name 'Pick up a gallon of milk'

    trait :completed do
      complete true
    end

    trait :not_completed do
      complete false
    end
  end
end

DRYing up: inheritance

Something that I wasn’t making much use of – you can nest factories, which allows you to create multiple factories for the same class without repeating common attributes:

factory :user do
    name "testing"

  factory :super_user do
    super_powers true
  end
end

Tracking factories

I followed the advice here to track factories. I think it’s useful to know how factories are being used.

If you want to go really in depth…

You have a very nice post on code reading of the factorygirl gem here. You can even learn something about how to do cool stuff in ruby/rails like:

 def set(attribute, value)
    @instance.send(:"#{attribute}=", value)
  end

And that’s all, folks (for now…)!

First of all, what is a factory and what do you need it for? Factories are a (healthier) alternative to fixtures, and fixtures are simply a “fixed state” for models, used as baseline for tests. In Rails, fixtures get automatically loaded into the test database before tests are run, and you define them in a YAML file. However, they can become awkward pretty easily, so Factories were created – frameworks designed to allow a quick creation of fully featured objects for testing.

And now you ask, why don’t we just create the object directly before each test? Think required attributes and associations – if your model has 10 attributes and 5 different associations you might want to have somewhere where you can create valid instances of that model upfront and then reuse them.

So, we have (somewhat) established what factories are for. Just beware of the downsides of using factories (quoting the blog in the link, which is highly recommended): “A big feature of tests is to give you feedback on your code. Tests and code have a symbiotic relationship. Your tests inform your code. If a test is complicated, your code is complicated. Ultimately, because tests are a client of your code, you can see how easy or hard your code’s interfaces are.”

Yup, I feel your pain, bro. My latest project has tons of models, polymorphic interfaces, STI’s, etc. Ultimately, flexibility creates complexity, and it’s better to avoid extra features to keep simplicity. But I digress.

So, how do we use these lil’ bastards? :-)

Configuration

The Getting started guide provides what you need. Except… I don’t think it’s that clear that if you are using Rspec, those lines

    require 'factory_girl'
    FactoryGirl.find_definitions

go in the spec_helper.rb file. More precisely, FactoryGirl.find_definitions goes inside the RSpec.configure do |config| block.

But: if you are using Spork, you need to reload Factory definitions at each run, otherwise you get a “factory not registered” error. So, place the following inside the Spork.each_run do block:

    Spork.each_run do
    # ....
        FactoryGirl.definition_file_paths << File.join(File.dirname(__FILE__), 'factories')
      FactoryGirl.find_definitions
    # etc...

There you go! Everything nicely configured :-) Also, you can use FactoryGirl in rails console! Just use the code in this post, which I’ll shamelessly copy here for posterity and for my own reference:

    ActionDispatch::Callbacks.after do
      # Reload the factories
      return unless (Rails.env.development? || Rails.env.test?)

      unless FactoryGirl.factories.blank? # first init will load factories, this should only run on subsequent reloads
        FactoryGirl.factories.clear
        FactoryGirl.find_definitions
      end
    end

You can also just run this code directly in the console. If you do have sequences defined, you’ll need to add the following extra:

FactoryGirl.factories.clear
FactoryGirl.sequences.clear
FactoryGirl.find_definitions

(and if you are using traits, apparently you need to add FactoryGirl.traits.clear as well).

In unit testing

So first things first… You can have a file for testing factories but I’d rather have the test for the validity of the factory in the model test file itself – this to avoid incurring errors when you are focusing on testing a particular model, all because your factory was ill-defined. So go ahead and test the factory itself:

    it "has a valid factory" do
        m = FactoryGirl.build(:my_model)
        m.should be_valid
    end

What do we do if this goes wrong and we can’t sort out the error? Go to the console, write

m = FactoryGirl.build(:my_model)
m.valid?  # duh, it'll be false
m.save    # just to trigger all validations callbacks etc that we might have
m.errors

And now go ahead and complete your factory with the necessary information. Simple enough, right? The syntax for defining factories is explained pretty well in the starting guide so I won’t go to the trouble, except for the case when we are using Faker.

With Faker

Faker is a cool gem for… you guessed it, generating fake data. And here’s how you do it:

  factory :company do
    name { Faker::Company.name }
    phone {Faker::PhoneNumber.cell_phone}
  end

Yup, just a normal block, not too bad.

Sequences

Sequences are used for attributes that must be unique, such as email addresses. You can define sequences “outside” of the factory definition, or inside as a block:

  sequence :email do |n|
    "test#{n}@example.com"
  end

    factory :user do
        email
    password "password"
    password_confirmation "password"
    phone {Faker::PhoneNumber.cell_phone}
    end

is the same as:

    factory :user do
        sequence(:email) { |n| "test#{n}@example.com"}
    password "password"
    password_confirmation "password"
    phone {Faker::PhoneNumber.cell_phone}
    end

Associations

Associations in factories are simply created by adding the factory name for the association in the other factory block. For example, if my user has_one location:

    factory :user do
        sequence(:email) { |n| "test#{n}@example.com"}
    password "password"
    password_confirmation "password"
    phone {Faker::PhoneNumber.cell_phone}
    location   # ta-da!
    end

More detail about associations with FactoryGirl here.

More about this tomorrow!

And this is scary. I wonder whether this is really true? I think that all the developers I know would pass the FizzBuzz test. Now I feel very much tempted to have my students code this in the next lesson… Mmmmmhmmmm…

On the same lines, from the creator of Rails himself, here is a short list of (5) books that help you program better. I think I’m going to order some of those. Probably the Smalltalk Best Practice Patterns. Look, here is an amazing set of slides based on the book to help me make up my mind: “Remember: the purpose of education is to save you from having to think” ROFL!

Yes, 70% of the time is spent on finding the intent of other programmers. And that’s probably because we don’t read enough code, because it’s more fun to just jump ahead at the problem and play with code than to try to figure out how things are done (guilty…). Along those lines, here is a cool article on “Code with Clarity”, where you have a step-by-step deconstruction of a very small function. And somewhat along those lines as well, here is a cool article on cracking gems and reading ruby code.

And finally, lately I have met programmers that fit into two sets: the first set is the linux hacker set. These guys are extremely fluent in all things linux-y and could probably code a whole OS in shell scripting. The second set tends to stay away from the shell like it’s the devil, they love IDEs, and think that man pages are ugly. So here is a little something for the second set: essential command line tools for web developers (and not just web developers). Terribly useful to know your way around a shell, you’ll need it someday.

And I think that’s it for the day. Now on to read & write some code…

But now I’ve been struggling with finding some true beginner tutorials for people who are new to Linux, don’t know that much English, and have an interest on using the Pi for more advanced controller stuff. So here is the list that I found so far – I’ll be adding more links as time comes (and possibly translating some stuff to Portuguese, so if you are interested in that, stay tuned)!

From Adafruit learning system

They have extremely nice (I mean extremely nice) step-by-step tutorials, exactly with the focus I wanted. Just perform a search by “raspberry” on their site and you’ll find:

• GPIO setup on the Raspberry Pi
• Raspberry Pi E-mail notifier using LEDs
• Reading analog inputs with the Raspberry Pi
• Playing sounds and using buttons with the Raspberry Pi

Other sources

This video tutorial from Geek Gurl Diaries is also pretty neat to learn something more.

I’ll be doing some of these projects myself and translating them to PT as I have the time. My ultimate goal is to be able to control the lights and blinders in my house with the Pi and to do some sort of home automation smarts but for now, I think I’ll stick to LEDs and not to 220V stuff :-) I also want to do some sort of intrusion detection system. Stay tuned!

Iphone and app stuffs

• This app, if it lives up to its promises, has everything that I’ve been wishing for and more. Basically, it’s a smarter contact manager that can aggregate not only contacts from your contact list, but also from social networks, it keeps track of how much you communicate with your contacts, spots trends, can create smart lists and take advantage of the information that you have in social networks to perform smarter searches. The interface is pretty awesome as well. My only complaint is that for now, I cannot add my Facebook contacts. When I do it, it completely resets the settings in the app (that’s the iphone app). Maybe that’s just a problem with my particular system, but I’m looking forward to seeing this working in my iphone, ipad (app hasn’t been released yet) and desktop (ahhh… automatic lists for sending e-mails in Xmas)!

• If your iphone home button is unresponsive (mine becomes from time to time, randomly so), here are four ways to fix it by our friends at c|net.

Web development tutorials and stuffs

This link has an assortment of the “best” nettuts tutorials, released month by month. The most interesting for me seem to be the “learn jQuery in 30 days”, closures with javascript, mobile-first responsive web design, javascript design patterns, and gem creation with bundler. For those that want to know more about topics such as agile development and vagrant (highly recommended) there’s something for every taste as well! I’ve been procrastinating learning more on frontend development because I find the backend problems way more interesting… I hope to follow these tutorials to learn more about these topics.

Fourier transform

Yup, I wish I had taken a signal processing class during undergrad. But I didn’t. And this interactive guide to the Fourier transform is a lovely start for those like me who didn’t have the wisdom to figure out the stuff that they needed on their own during undergrad. Amazing explanation!

Three Crowdsourcing Projects that are Advancing the Medical Field

I really really believe in the power of crowdsourcing for advancing our knowledge of medicine and of the human body. Medicine as it is practiced nowadays seems so… retrogad. As a friend of mine put it, the best doctors for ourselves are ourselves. There are so many things that doctors just cannot know, so many new weird conditions… So why not harness the power of the people? That’s what these crowdsourcing projects aim to to.

Security random stuffs

A very cool article/podcast interviewing Robert Watson about the shifts in computer security, especially from an OS security and exploits point of view.

An app that attempts to mitigate the side effects of these problems (such as accessing the data in your phone) is remotium, where a good friend of mine (José Luís Pereira) is working. Do check it out – they have a cool video of an android exploit being performed live.

Clipboard buffering for OS X

How can you live without it?

I chose flycut, which is based on jumpcut but seems to be updated more often (as we can see by the choice of github and not sourceforge :-) ). Highly recommended, you’ll never know how you could live without it.

Really assorted links

• One topic that really comes to my mind often, especially now that I teach at the University, is how much college is worth exactly. This article gives a nice blunt opinion on why college still matters (but to be honest, I do think that we should not go straight to college out of high school – not because we don’t know what we want exactly, but also because we don’t know how to appreciate and select the most important topics for us to focus on. I view my undergraduate experience completely differently as of today!).

• Another proof that only execution matters is DeveloperAuction. I had something similar to this idea years ago… but of course, never executed on it, and it doesn’t mean that I would be any successful if I tried ;-) The article is very interesting. The “world” is very different for developers engineers in the US!

Call for help

If anyoone has any idea of why the code in my gists appears centered and not nicely indented as nature intended it to be, please let me know. I am using Octopress and Slash, and the gists are stored in Github (where they do indeed appear nicely indented).

So, suppose that we have a model like

# == Schema Information
# Table name: Bla
#  test       :boolean
class Bla < ActiveRecord::Base
  attr_accessible :test

For example, if I had used validates_presence_of :test in the example above, it would have failed miserably because false.blank? is true – so in practice, we could have never set bla.test to false, since it would make the validation fail (more details here).

So I set out to try this out:

validates_inclusion_of :test, :in => [true, false]

and test it like this:

it {should_not allow_value("bla").for(:completed)}

and it still failed miserably.

Now I was puzzled… So I tried this one out:

I was thinking that at some point the test attribute would be set to “bla”, but since the field is a boolean, inserting other values will always evaluate to false. So we don’t have to go to all this trouble: this way we can validate the presence, but we never need to validate whether the value itself is valid. More about this here. Living and learning!

• testing – ok, RSpec does make things a tad more complicated for testing. I believe that testing actually makes you learn more about what you code, and RSpec, being a DSL, can make things esoteric enough that sometimes you don’t know exactly what you’re testing (I confess that I like Test::Unit more because it’s simpler for developers to read – assert that this gives this result). But, on the other hand, you have shoulda! :-)
• documentation – the exact same thing that makes testing a bit more esoteric, makes documentation a piece of cake. You want to know how something works? Just read the tests. And RSpec does make that side of testing much clearer.
• TODO – yup, that’s right. If you have features that you want to implement later on, just add a “pending” spec with the description of what you want to do. Of course that you can do that in Test::Unit as well, but it’s not as beautiful and immediate as in RSpec.

Of course that I’m really just beginning and I might change my mind eventually. Even the creator of Rails argues against RSPec, and there are quite a few arguments against it (if you missed the link, here’s an excellent blog post on that).

By the way, I’m abiding by this rule from the last post:

”- Keep things flat — deeply nested contexts are ugly as they hinder readability of your test cases. Split your tests up into different files if they’re getting too long.”

I was trying to make things DRY in the tests, and then I thought… why bother, exactly? It’s better if they are more readable, for the sake of documentation as stated above. Amen, brothers.

Why not Cucumber for request specs?

All the reasons are in this excellent post.

From rails guides:

“Ideally, you would like to include a test for everything which could possibly break. It’s a good practice to have at least one test for each of your validations and at least one test for every method in your model.”

Which leads me to…

Why I use shoulda

I think that the best thing is just to take a peek at The shoulda cheat sheets.

You actually get a guide of what to test by looking at the cheat sheet! It’s too bad that it’s not up to date (actually I think that the whole site is not up to date – even the gem doesn’t work anymore, which I think is too bad :-( )

Furthermore, it’s great for lazy people and it’s definitely easier on the eyes. Just check the following example:

Convinced? ;-)

What I test exactly with shoulda

I go through the whole list of shoulda macros for models, and I just use and abuse them. Since the cheat sheet is not up to date, I created a new one (just for models for now) at:

Yes, it’s a bit tedious. But (1) you make sure that you are actually testing all these details, which is extremely useful when you are constantly refactoring your code, and (2) it’s not that slow with the multiple cursors of Sublime Text 2. You just need to have a scaffold.

What I test without shoulda

Apart from model methods, is there that much to test without shoulda? I test:

• Any model methods, extensively
• Callbacks, extremely extensively
• Some validations - but just to make sure I coded them right. See more of this perspective in Testing model validations in rspec the short and sweet way

… and for now, that’s about it.

Regarding generating fake data

Like I mentioned before, I do use FactoryGirl extensively. Maybe that means that my models are complicated? I don’t know, but for now, I am sort of using good sense and stuff. Let’s see what happens. I do use Faker as well. Come to think about it, will do a post on that eventually.

Random issues in testing models

When everything seems to be absolutely correct in the models and in the tests and you are still getting unexplainable errors, do restart guard. I already spent several hours messing around with the tests because guard didn’t refresh the models. There are automatic solutions, but I didn’t feel like hacking away the spork/guard configurations again… yet.

Random resources

• Everyday Rails: How I learned to test my Rails applications, Part 3: Model specs - this has a very nice overview of the actual steps required to test models. Now I just cheat using shoulda, but it’s very nice and useful to get a

• Testing model validations in rspec the short and sweet way - it’s a bit outdated, but describes how to test validations in a short way.

Again, as I already mentioned, I am a beginner to rails and, consequently, in testing rails, so I might be doing/saying terribly wrong things. Any input is very much appreciated :-)

How great leaders inspire action

The fact is that this is what attracts me (and many people, probably) to startups. It’s just easier to find this sharing of common beliefs – and if it’s not, it’s the wrong startup.

People don’t buy what you do, they buy why you do it.

People buy what you believe in. Somehow this makes me believe in mankind a bit more :-)

I don’t know whether this library is very common, but it definitely shows a lot of promise:

Segmentio’s Analytics.js

It provides provider-agnostic hooks to route to analytics services. They also have a hosted version where the analytics services can be changed without touching the code. Looks really clean and neat.

Nice video: to_proc

This video by CooperPress explains in a very clear fashion how to use the “to_proc” feature of Ruby (and understand some weird code you might come across). It is also well worth it to subscribe to their other videos.

Faster Rails partial rendering and caching

I sure will try out this gem (multi_fetch_fragments) to optimize Rails when I get to that point of my work…

Indexes in Rails databases

Extremely good article by Tom Ward on using indexes in rails associations. An excellent guide to determine what indexes your app should include (no more, no less).

Gems I use

I test using rspec and shoulda, which dramatically reduces the size of the tests. But beware – rspec is a DSL, and I think that I only got a bit more intuition on what I was exactly testing after doing some tests in Test::Unit. I also use FactoryGirl for setting up the test data, instead of fixtures. Last but not least, the simplecov gem is amazing, and although you shouldn’t rely on it to determine when to stop testing, it really is good to get a (very precise) sense of what’s covered and what’s not in their beautiful html reports.

General tips

When all your tests are red for no apparent reason, it’s because you were messing around with the db and then forgot to do

rake db:test:clone

Yup, the reason I am mentioning it here even though it seems completely obvious is because I am distracted and do that a lot… :-)

Tips for running guard/spork in vagrant

I use vagrant to keep my environment all neatly in one place. However, there are downsides. When running guard inside the guest OS, use

bundle exec guard -p

Otherwise, guard won’t detect changes in the guest filesystem.

FactoryGirl tips

You can keep all factories in one file, for me that is more intuitive (and also, I don’t have to keep opening files while I’m testing, it’s all in one place.)

To try FactoryGirl methods in the console, run:

FactoryGirl.find_definitions

At least in my case, I would get a factory not registered error when I didn’t do that.

Better Errors

Not exactly related to testing, but this gem has been a life changer! When there is an error, the standard error page gets replaced by a much better and useful error page, which has a full trace, the local and instance variables that are set at the time, and a terminal that you can use to inspect and make changes to the variables in the models and controllers in real time (or code whatever you want). I know I already mentioned it in another post, but I can’t stress enough how cool this gem is!

In the next posts, I’ll give an overview of how I test the models and controllers, which I only started testing this week!

 # spec/spec_helper.rb
Rspec.configure do |config|
    config.tty = true
    config.color_enabled = true
    # ... whatever configurations you might have here...
end

And enjoy a more colorful life ;-)

Here’s a very nice article on the options for setting environment variables in Rails

Why would you want to set environment variables in rails? There are some examples in the article, but for instance, setting passwords to access services. They should not be in any file (nor tracked in git), so that other people cannot access them. One way is to set Unix environment variables, the other way – which actually sounds like a “cleaner way” of organizing things – is to set them from Rails itself by taking the values from a yaml file.

(By the way, for those with Mac OS, the command line instructions here) are very nice and comprehensive.

So now on to the cool stuff… Initally I had installed TightVNC, but could not connect to the same session as being displayed via HDMI (which is console 0). I don’t know whether that’s possible with TightVNC, but I sort of got tired of trying. So here are the steps to make it work, which basically consist of installing x11vnc instead of TightVNC and having your desktop manager autostart it:

sudo apt-get install x11vnc
11vnc -storepasswd

# to create the autostart entry, do:

cd .config
mkdir autostart
cd autostart
nano x11vnc.desktop

# paste following text:

[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=X11VNC
Comment=
Exec=x11vnc -forever -usepw -display :0 -ultrafilexfer
StartupNotify=false
Terminal=false
Hidden=false

… aaand it works :-) For more details check the original link.

First, install mplayer if you don’t already have it:

 sudo apt-get install mplayer 

Then, open ~/.mplayer/config and pimp your player by adding the following settings:

 cache=8192
cache-min=4 

Next, clone the gsclient plugin by drakedevel:

 
git clone https://github.com/drakedevel/gsclient.git

And now… RoCk and RoLL :-)

Just installed this gem – Better errors. It is a gem meant to help you out in development mode that replaces the standard Rails error page with a wayyyy better and more useful error page, featuring full stack trace, source code inspection for all stack frames, local and instance variable inspection, etc.

I’m going to try it out today, but definitely beats the time spent looking at development logs (even if they are as clean and contained as mine after doing the changes described in this post).