Friday, 31 July 2009

A little thing that saved me

Factory Girl stringify_keys error in Create Test.

Now have to work out why everything else is going wrong ... I think I have to work out how to stop other classes from screwing up the thing I am testing. Sounds like I need stubs and/or mocks. Just have to work out how to use them ...

Tuesday, 28 July 2009

Rich list of cucumber tutorials etc

http://wiki.github.com/aslakhellesoy/cucumber/tutorials-and-related-blog-posts

redgreen not working

Could not get this bugger to work at all.
After much fiddling around - and a lot of googling, the penultimate comment on here solved it.
There was a lot of talk on sites about edit the .autotest file - but, er, on my install I had three .autotest files - which one to edit?
As it turns out, none of them. I had to make my own in the ~/ directory.

I am using SSH to remote into a RHEL5 box.
did a
$> vim ~/.autotest

got the usual vim type new file thing
and then typed

require 'redgreen/autotest'

yes - that way round, and NOT require 'autotest/redgreen'.
Save that (remembering not to hit Apple-S which sends Vim into a right old state) and at long last glorious living technicolour. Well, red and green at least - oh and amber too.
Second step on the journey of a thousand miles.

Having spent some time trawling around and looking at testing, and following the advice of the ever sagacious Ryan Bates, I think it is worth investing the time and effort in getting a solid test environment built.
To that end it looks like the following
Mocha
RSpec
Cucumber
Webrat
FactoryGirl.
It worries me that that is five packages to try and get working. However, I have got the Unit tests working pretty well so far using fixtures etc.
I think I am going to try and use FactoryGirl rather than fixtures. My brief foray into fixtures was not a happy one. They seem very brittle.

Monday, 27 July 2009

Factory Girl

Wow - doesn't take long to get pissed off with fixtures, does it? They are incredibly brittle and I spent a load of time hacking fixtures to get them to pass the tests that I knew it would pass. Seemed like a pretty good waste of time.
Soooo - truffling around I found the excellent Ryan Bates had produced a very useful railscast on Factory Girl which seems - one functional test completed - to be a lot better.
I still want to get my head around cucumber and rspec - even shelling out a few bob to buy the book.
It seems very much the right way to go.

Friday, 24 July 2009

test, test, test

Ok. Have managed (eventually) to get all the Unit tests to pass. That was a very illustrative experience and highlighted some issues - such as not getting all the associations completely nailed.
Funny how a quick "test" in the browser isn't really up to the job at all.
There are some issues with testing callbacks - doesn't seem anyway to pass information to and from the callback.

Now trying to crack the controller tests. The scaffold tests have, so far, failed in rather too many ways.
1) Failure:
test_should_create_brisque_set_up(BrisqueSetUpsControllerTest) [test/functional/brisque_set_ups_controller_test.rb:16]:
"BrisqueSetUp.count" didn't change by 1.
<3> expected but was
<2>.

2) Failure:
test_should_update_brisque_set_up(BrisqueSetUpsControllerTest) [test/functional/brisque_set_ups_controller_test.rb:35]:
Expected response to be a <:redirect>, but was <200>


Not quite sure why this should happen since this is an untouched-by-human-hands object.
We'll find out ...

Monday, 29 June 2009

So far, so good

It is Mao's journey of a thousand miles, it begins with one step. So far, most problems have been resolved by throwing enough time and hard work at them.
The next problem - a recalcitrant radio button that refuses to pick up its value:


<%= f.label :verhorcut, "horizontal" %> <%= f.radio_button :verhorcut, 0 %>
<%= f.label :verhorcut, "vertical" %> <%= f.radio_button :verhorcut, 1 %>



there is a field called verhorcut - it is returning the correct value, but so far seem unable to pick up a value for it. In the schema it is a boolean so have tried "0", 0 and "false" but nothing so far.
Keep plodding away.

Next on the agenda - some proper unit testing.

Tuesday, 23 June 2009

Everything comes to he who waits

Problem solved. It was behaving very oddly - as if the class didn't really exist properly. Rebuilt the controller and now all works. Hurrah.

Next problem.
Have three classes:
class StoredFile < ActiveRecord::Base
belongs_to :job_store_path
belongs_to :job_set_up
accepts_nested_attributes_for :job_store_path, :allow_destroy => true

class JobSetUp < ActiveRecord::Base
has_many :stored_files
has_many :job_store_paths, :through => :stored_files
accepts_nested_attributes_for :stored_files, :allow_destroy => true
accepts_nested_attributes_for :job_store_paths, :allow_destroy => true

class JobStorePath < ActiveRecord::Base
has_many :stored_files
has_many :job_set_ups, :through => :stored_files

The idea is to generate suggested path names for files, but then store the actual path name so that should the structure change, the old files are not going to be lost.
This works fine:
<% @job_set_up.stored_files.each do |stored_file| %>
<%= content_tag(:strong, stored_file.job_store_path_id) %>
<%=stored_file.address %>

<% end %>

But what I really want is:
stored_file.job_store_path.name - but if I do this I get:

NoMethodError in Job_set_ups#show

Showing app/views/job_set_ups/show.html.erb where line #11 raised:

You have a nil object when you didn't expect it!
The error occurred while evaluating nil.name


Ho hum.