jcteague / autofixturejs Goto Github PK

is there any furture plan to support auto foreign key generation?
that would be great.

Are there @types/autofixture?

This project has been around for a long time. When I first started it, it was pre ES6 and the internals is starting to show it's age it's time for a rewrite.

Fixture Definition

I think the fixture definition api has stood to the test in time and I don't forsee making any changes to how fixtures are defined, but export them seperately so you can import them directly into your tests.

const UserFixture = Factory.create('User', [
  'firstName',
  'lastName',
  'email'.asEmail(),
]);
module.exports = {
  UserFixture,
}

However, a plugin approach for builder functions might be interesting so you could create new types of builders could be interesting. It's not hard right now, just add a function following the pattern of existing builders. But you have to add it in all tests, or setup to use.

Factory.addBuilder('customValueBuilder', (fieldName, increment, {param1, param2}) => {
  return value_for_field
});
const UserFixture = Factory.define([
  'customValue'.customValueBuilder(1, 2),
]);

Fixture usage

Moving to module import approach to using a fixture, first suggested in this issue

const {UserFixture} = require('../fixtures')
const fixture1 = UserFixture.create();  //simplest use, all defaults
const fixture2 = UserFixture.create({
  firstName: 'firstName', //  simple overiding
  email: (incrementer) => `email${incrementer}@example.com` // new feature
});
// exists today, but a little clunky
const fixture = UserFixture.create((fixture)=>{
  fixture.firstName = 'firstName'
});

Any other suggestions?

I'm going to start work in this version this week

Hi

Please accept my apologies if you consider this a misuse of a GitHub issue.

I came across this project today because I have a search agent set up to watch for the name AutoFixture, and just wanted to drop you a line... Please read on, this isn't a cease and desist letter - just a friendly note that the name may confuse some users...

The reason I have a search agent looking for the name AutoFixture is that I'm the inventor and Benevolent Dictator of a fairly successful open source project called AutoFixture.

Now, you are entirely free to use the name AutoFixture for a Javascript implementation - you probably arrived at the name the same way that I did. However, I just wanted to point you to the existing AutoFixture project, because it may be a potential source of confusion to users.

Obviously, node programmers are likely to be blissfully unaware of the .NET AutoFixture project, but people with prior experience with AutoFixture for .NET may be confused if autofixturejs uses completely different concepts, etc.

Additionally, it may make it difficult to search for AutoFixture documentation, etc. The reason I'm writing is that this has the potential to confuse both AutoFixture .NET users, as well as autofixturejs users.

Perhaps we could deal with such potential issues in one of the following ways:

• Align the concepts and names etc. between the two projects. A couple of years ago, @moodmosaic expressed an interest in creating a port of AutoFixture to Javascript, and although I don't currently have the bandwidth to pour a lot of hours into this, I'd certainly be interested in using it myself. Perhaps we could even make autofixturejs part of the AutoFixture GitHub organisation.
• Perhaps find another name for this Javascript project.

You are completely free to ignore this message, and keep working on your project. My motivation for writing to you is only that, based on the ReadMe for this project, it looks like you're unaware of the existing AutoFixture project, and I just wanted to point out to you that prior art exists, and that it may confuse your potential users.

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