Add Factorygirl as an alternative to fixtures

[gravitystorm]

FactoryGirl is a widely used alternative to fixtures in tests. The fixtures are annoying since every time you want to test something slightly different (for example, a diary entry with an apostrophe in its title), you need to add a whole new fixture and rework the tests. Fixtures are also a pain when the model attributes change.

This PR adds FactoryGirl, and reworks two model tests (DiaryEntry and DiaryComment) to use them.

[tomhughes]

This test name doesn't really reflect what the test does any more... Then again I'm not really sure what it is testing now - is it actually just testing that FactoryGirl can create records? or does that itself funnel through the rails code so that we're testing rails can create records?

[tomhughes]

I wonder if a more canonical way to do this is something like:

diary = create(:diary_entry) do |diary|
   diary.comments.create(attributes_for(:diary_comment))
end

I mean I don't really know if it's any better or worse, it's just the sort of thing I was seeing in the FactoryGirl docs.

[tomhughes]

Then again maybe we should leave it as is but add an assertion that there are zero comments before that create...

[tomhughes]

I this not just entry = build(:diary_entry)?

[tomhughes]

Indeed can we not merge it with the next line as:

entry = build(:diary_entry, attrs)

[gravitystorm]

Thanks for the comments. One of the problems is that the original tests are a bit pointless - they are mostly asserting that the fixtures have loaded, or that Rails itself is working (e.g. build a model from attributes, whatdoyouknow, the model has those attributes). The refactored versions are still mostly trivial, and often a bit pointless too.

I would prefer to rewrite most of these tests completely to test our "business logic" instead. But I was wary of trying to do too many things at once, since I'm always suspicious when people start rewriting tests instead of refactoring them!

I'll fix the specific points you've raised, and make a separate PR with some more thorough rewriting.

[tomhughes]

Yes I always find that a lot of model tests involve a fair bit of "what exactly are we really testing here" head scratching...

I mean obviously if you have a method with some additional logic in it on a model that's fine and can be tested but a lot of the time the tests as you say seem to be testing rails more than our code. I think things that make sense in a model test are:

• That any additional methods written by us work
• That associations return the expected records, especially where they involved filtering, ordering, etc
• That validations allow/reject the correct things

On the other handing, testing that count returns the right number of records is probably less useful ;-)