At the Forge - Fixtures and Factories

<h1>New meeting</h1>

<% form_for(@meeting) do |f| %>
 <%= f.error_messages %>

 <p>
  <%= f.label :starting_at %><br />
  <%= f.datetime_select :starting_at %>
 </p>
 <p>
  <%= f.label :ending_at %><br />
  <%= f.datetime_select :ending_at %>
 </p>
 <p>
  <%= f.label :location %><br />
  <%= f.text_area :location %>
 </p>

 <p>With:
   <%= select("person",
              "person_id",
              Person.all.collect { |p| [p.fullname, p.id] },
              {},
              {:multiple => true}) %>
 </p>
 <p>
  <%= f.submit 'Create' %>
 </p>

<% end %>

<%= link_to 'Back', meetings_path %>

I also created a convenience function that returns an array of names with whom the appointment will be:

def people_as_sentence
  return self.people.map {|p| p.fullname}.to_sentence
end

This validation, which is run whenever I try to save an instance of Meeting, checks to make sure that the starting time is earlier than the ending time. If this is not the case, the validation fails, and the data is not stored. (The fact that I can treat times as full-fledged objects, with access to the > and < operators, is one of my favorite parts of both Ruby and SQL.)

Finally, I'm going to enhance this application by modifying the existing scaffolded controller actions to be more useful. First, I modify the new and create actions, such that they will allow someone to create an appointment, simultaneously indicating the person or people with whom the appointment will take place. Then, I modify the index action, so that the user will get a list of all upcoming appointments.

Now that I've created a simple application, the time has come to test it. As I wrote above, testing the application requires that I have some sample data with which to test it. By default, the generators for Rails models create basic fixtures, which have long been the standard way to import data into Rails tests. By basic, I mean that they contain some very, very basic data—too basic, actually, for any real testing I might want to do. For example, here is the automatically generated fixture for people:

one:
  first_name: MyString
  last_name: MyString
  email: MyString

two:
  first_name: MyString
  last_name: MyString
  email: MyString

Even if you are new to reading YAML, let alone fixture files, the format should be easy enough to understand. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. (You also can associate a list of values with the key, by separating values with commas.) Thus, there are two people defined in the fixture, one and two, and each has three name-value pairs.

However, these name-value pairs are close to useless. They might contain valid data, or they might contain data that fails to adhere to the standards laid out in my model validations. If I had defined a validator for the email field, ensuring that the field always would contain a valid e-mail address, the tests would fail right away, before they even ran. Rails would load the fixtures into ActiveRecord, the database would reject them as being invalid and I'd be left scratching my head.

Things get even hairier when you start to make fixtures that depend on associations. I obviously want my meeting_people fixtures to point to valid people and meetings, but using the numeric IDs can get confusing very quickly. Fortunately, recent versions of Rails allow me to name the fixture to which an object is associated, rather than its numeric ID. Thus, although the default fixtures for meeting_people is this:

one:
  person_id: 1
  meeting_id: 1

two:
  person_id: 1
  meeting_id: 1