Does this package work?

[steve-ross]

> meteor shell

> Fixtures.saveFixtures();
TypeError: Cannot read property 'name' of undefined
  at Object.Fixtures.Fixtures.saveFixtures (/Users/sross/tourify/.meteor/local/build/programs/server/packages/ryne_fixtures.js:56:58)
  at repl:1:10
  at /Users/sross/tourify/.meteor/local/build/programs/server/shell-server.js:243:23

>which mongodump
/usr/local/bin/mongodump

[ryneeverett]

I reproduced. Thanks for the report. I hadn't tried it with no arguments recently.

The package does work, but I seem to have introduced a regression.

[steve-ross]

thx, yeah adding a name parameter seemed to fix it.

[ryneeverett]

Yeah, I broke the default argument handling for saveFixtures. Will have a fix up in a minute.

[steve-ross]

Also, what is the best way to go about using these bson files, I get your 'before' function but, there isn't really an example of using the data in the ReadMe. Just a thought

[ryneeverett]

Just pushed 0.0.2 to atmosphere. Thanks again for the report and let me know if you have any further troubles.

[ryneeverett]

Ah, I missed your question. I'm using the fixtures to load collections that my application consumes directly. I don't access the collections in test (though I could). Do you think showing an example of adding a collection before saving and then accessing it after loading would be helpful?

[steve-ross]

yeah that would be helpful. I guess I was under the impression that the package would actually create fixtures based on the data in the db. Sounds to me like it does more of a mongodump and then a load of that data before you run the tests?

[ryneeverett]

Sounds to me like it does more of a mongodump and then a load of that data before you run the tests?

Exactly, though I'd like to figure out how to copy the database without those utilities. See #1.

I was under the impression that the package would actually create fixtures based on the data in the db.

I'm not exactly sure what you mean by "create fixtures based on the data".

[steve-ross]

I just meant it would be great if you could create fixture.js files that you could edit as your project grew.

[ryneeverett]

Gotcha. I'm basically doing that in my app -- I have a script I'm tracking which populates my database before I save it.

I guess I'm not sure what the advantage of having such scripts run by the fixtures package would be. The reason I use fixtures (rather than repopulating the database with the script on every test run) is that the script is too expensive to run every test run. In my case this sped up my test suite 10x because my script makes a bunch of remote API calls.

I suppose this package could check a file for changes on every test run and then run it and do the saving automatically, but that seems like a lot of magic just to avoid running the script and saveFixtures each time you change it. (How often do you modify fixtures, really?)