Is it possible to use factory as module?

[entropitor]

Instead of defining a name for the factory model, just return it so it can be exported and the ES6 module system can be used to resolve fixtures

[jcteague]

That's an interesting idea. One of the key features is the ability to customize the object the fixture returns to meet specific test criteria. How would you propose to do that with an import statement?

A PR would be welcome!

[entropitor]

You mean that you can override properties? I think that should still be possible.

At the moment I started using rosie, they allow both to import by ES6 modules and to use the singleton pattern that you are using.
See https://github.com/rosiejs/rosie#usage-in-es6

[jcteague]

Interesting. Rosie looks like it follows a lot of the same patterns autofixture does.

I do see some advantages to do it this way.

It's possible to simulate this now if you export the build function in the Rosie example

// user-fixture.js
import {AutoFixtures as Factory} from 'autofixture'
Factory.define('user', ['first_name','last_name','email']);
export default function(overrides) { return Factory.create('user', overrides) }

// test.js
import { UserFixture } from 'user-fixture';
const user = UserFixture({email: 'test3mail'});

It would not take much to refactor autofixture to make this easier.

[entropitor]

Yes although, multiple models can't define the user factory because of the singleton global namespace

[jcteague]

You do not want multiple fixtures of the same model defined. Doing so could introduce hard to find bugs in your system due to different shaped objects in different tests.

…

On Sat, Sep 9, 2017 at 10:51 AM, Jens Claes ***@***.***> wrote: Yes although, multiple models can't define the user factory because of the singleton global namespace — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAElJi5_3xNL0xq5LJ9uoVsz42fGL7Jmks5sgrP5gaJpZM4POHBe> .

[entropitor]

They might be completely different objects that happen to have the same name. If you're reusing the module system, I don't think you need to complicate that with a global namespace

[jcteague]

I would accept a PR that made it easier to import a fixture through an import / require statement, but not one the allowed different objects with the same name.

…

On Tue, Sep 12, 2017 at 4:53 AM, Jens Claes ***@***.***> wrote: They might be completely different objects that happen to have the same name. If you're reusing the module system, I don't think you need to complicate that with a global namespace — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAElJn17g1gPxxbSA9WUJRK7oLhWNLKAks5shlSggaJpZM4POHBe> .

[jcteague]

I just added this feature to v1.1. I haven't documented it yet, but there's a couple of tests to show the return object from a create call that can be exported