7

I'm considering migrating many mocks from FactoryGirl over to the Fabrication gem.

However, so far I've been unable to find any information on implementing the trait pattern available in FactoryGirl.

Is there a generally accepted way to do this with Fabrication?

Thank you in advance for any answers or information.

ocodo
  • 29,401
  • 18
  • 105
  • 117

1 Answers1

10

Fabrication doesn't have syntax sugar for traits. As far as I understand, it is just a way to group and define inheritance.

In the case of this Factory: (which I pulled from this blog post)

FactoryGirl.define do
  factory :todo_item, aliases: [:incomplete_todo_item] do
    name 'Pick up a gallon of milk'
    complete false

    factory :complete_todo_item do
      complete true
    end
  end
end

You would do the same thing in Fabrication like this:

Fabricator(:todo_item, aliases: :incomplete_todo_item) do
  name 'Pick up a gallon of milk'
  complete false
end

Fabricator(:complete_todo_item, from: :todo_item) do
  complete true
end

If you do decide to convert you can send to the mailing list with any specific questions. I am always happy to help figure out how to get things working or improve the efficiency of your fabricators.

Paul Elliott
  • 1,174
  • 8
  • 9
  • Thank you Paul, effectively traits help to avoid duplication and keep mocking factories in FactoryGirl DRY. It's this duplication that concerns me about Fabrication – ocodo Apr 06 '15 at 03:48
  • I don't think traits add any real value. The fabricators I laid out above are as DRY and more concise than their trait-based counterparts. Could you give me an example of what you're doing with traits that actually makes it a beneficial feature? I have never seen a non-trivial example of it being used. – Paul Elliott Apr 06 '15 at 12:29
  • We are using them to setup complex models which will have small (but crucial) differences, which affect how business logic is processed. To implement them as separate Fabricator objects, appears to me at least, to require a large amount of duplicated boilerplate. – ocodo Apr 07 '15 at 00:43
  • As an example, say we have a Personnel record, which has attached lists of email addresses, phone numbers, profile photos, emergency contacts, etc, etc. Say we want to make tests to assure objects behave as expected when there are multiple emails addresses, some of which may be in a domain whitelist (or blacklist) ... We'd usually assign traits to provide these associations. To be honest, there are so many cases where we use traits to set small changes on mock models that it's a little inadequate to show a single example. If you have time, I would like to discuss this further. – ocodo Apr 07 '15 at 00:48
  • To quote the blog post from ThoughtBot - "Traits are a great way to add individual pieces of state to a factory without having to implement a massive hierarchy." ... It's avoiding this massive hierarchy that it in question here specifically. – ocodo Apr 07 '15 at 00:50
  • It seems to me that the cases you've defined above may not need explicit fabricators defined. When writing tests, you should be explicit about things that matter to that test, such as the expectation for multiple email addresses. It is very hard to say without actually seeing your test suite though. – Paul Elliott Apr 07 '15 at 12:31
  • I would be happy to discuss this in more detail if you'd like, but we should probably take it to a private conversation. Reach out directly anytime. – Paul Elliott Apr 07 '15 at 12:33
  • Thanks @PaulElliott I'll drop you an email. – ocodo Apr 07 '15 at 12:36