I’m just getting some tests written with Chimp and i’m wondering what the best way to get data to my feature tests is. Current I have a test that logs in as a user and checks what it sees, but I want to create fixture data before my tests run so I can check the data is there
Currently the data I have access to is available because I have seed data in my app, I start my app with meteor run and then point Chimp to it.
Also, because my app tests are located in /tests/ of my meteor directory, I don’t have access to any of my collections and so forth.
Is there a way to do this with fixtures, or do I just need to seed my app with data and test with that? Any ideas appreciated.
Method 1:
You can setup a fixture package that is debugOnly and expose some Meteor methods in that package that allow you to create data
Method 2:
Use Chimps server.execute to call methods inside the Meteor server context. There you’ll have access to the collections
Method 3:
This is really an extension of Method 2, in that you call sever.execute, but you do so from a fixtures.xxxx namespace. That way, you can centralize the logic to create test data.
A word of advice, rather than create and maintain dumps of data that you use in the fixtures, if possible create a nice API that allows you to create the data inside the fixtures namespace, then set up the data programmatically as needed for each test/scenario. So for example:
// SETUP
const userId = fixtures.users.create({});
const rubberChicken = fixtures.items.create('rubber chicken');
const yellowHat = fixtures.items.create('yellow hat');
const items = [].push(rubberChicken, yellowHat);
fixtures.shoppingBasket.add(userId, items);
// EXECUTE
// call the System Under Test (SUT)
// VERIFY
// through the UI/API end point/whatever
This is the most readable and maintainable way I know to create fixture data. You put a bit of extra time into your fixtures API, and then it makes it very clear what your test is doing.
If you are using a Service Oriented Architecture or Domain Driven Design, or something else that exposes business logic as services, then you should not go directly to the collections to add data where possible, but instead use the actual services from your app. This makes the code even more maintainable and the fixtures become a thin orchestration layer.
VERY helpful. Thank you, I like Method 3 and will be giving that a go, I’m already taking extra time to actually do testing so a little more to make them more maintainable just makes sense. Thanks again, I will post my results