Day 5: Fixtures and Testing

I’ve been developing this system using a live Basecamp connection, but testing and debugging is made a lot simpler when one works with a static data set. All rails model unit tests include a fixture reference — this defines the static data set against which the model’s unit tests are written.

I wrote up some YAML to define sample people, companies and projects by hand. Timeentries are too numerous to write out manually, so I opted to generate them. Due to my time constraint, I am randomly distributing time entries to projects, people and dates. Any model or controller logic that interprets this data must reflect this random distribution in order for my test to pass.

This test is not reliable: there is a finite chance that the test will fail — even with a large number of time entries. This ham-handed approach is suitable only for first-inspection testing, and should be replaced by a documented model if this interface ever finds serious use.

For the code-curious, here is my timeentry YAML fixture definition:

<% for i in 1..1000 %>

<% entry_date = DateTime.now()-rand(30)
y = entry_date.year.to_s
m = entry_date.month.to_s
d = entry_date.day.to_s
if (m.length == 1) m = "0"+m
if (d.length == 1) d = "0"+d
date_str = y+m+d %>fix_<%= i %>:
  id: <%= i %>
  person_id: <%= rand(3)+1 %>
  project_id: <%= rand(5)+1 %>
  hours: <%= rand(0)*8 %>
  date: <%= date_str %>
  api_login: philippp
<% end %>

3 and 5 should be defined as external constants and used to generate people and projects: 3 is the highest person_id of employees (in my dataset, employees come first — only employees have time entries) and there are 5 mock projects.

~ by philippp on June 19, 2007.