Disable file parallelism for api-DB integration tests
I will be using vitest and supertest with express as my backend framwork to test my REST api.
I have beforeEach blocks in my test files to wipe the db state and fill it with dummy data so each test has same DB state to work with.
Vitest by default runs the tests in different files concurrently. The problem with this is that the different tests might conflict with each other as they might insert same data that invokes validation violation. I can disable file parallelism in vitest just for these database tests so that they are run one after another even if they are in different files.
I have read some posts online and they seem to say that this is not a good idea and that either each of my tests should use a different database or each test should use data that's independent of other tests.
I have no idea how to do the first one, I read about tests containers but that seems overkill for something that's basically just a learning project.
For the second one I'm not sure how to do it without having to keep track of what data is used in which test. I might forget or as tests grow in numbers in might become complicated.
I'd appreciate any input, thank you for your time
21 Replies
why don't you create a temporary table for each test, with the data at the stage it should be?
I'm not sure what you mean by this.
say if I have a table named
blogs. Should I go like this - blogs_get for get testing blogs_put table for post testing? but if I do this I'm not sure how I will make my orm point to those specific tables
since the orm schema doesn't have these tables and the api controller is also using certain named tablesmore like "temp-table-1", "temp-table-2"
and you create the temporary table in each test
hmm but how would the orm know to use that table?
if I make a get request to
/api/blogs with supertest, the controller for the route uses the orm cilent to retrieve the blogs in the blogs table. I would somehow need to make the cilent point to my temp table insteadoh, you are using one of those funky database thingies over http
well, the best is to rtfm to see what they say about testing
https://www.prisma.io/docs/orm/prisma-client/testing/integration-testing
they basically say to use docker which I wanted to avoid since it seemed complicated and I haven't used it before
I guess I'll see about learning docker
that's integration testing, not unit tests
that is VERY VERY different
Isn't what I am doing integration testing?
I'm checking how the api and database work together.
Wouldn't unit testing be more like 'this function should return all blogs'
The way I have phrased it might sound like all my tests are unit tests but there will also be tests like
'only allow deleting a blog if the logged in user is the owner of blog'
Which will need the api to first login the user then check against the database if blog id has correct user id as foreign key
https://github.com/GaneshS288/FullStackOpen_Part_4/blob/main/blog_list%2Ftests%2Fblog_api.test.js#L100
This is not the same project and it uses odm because mongodb but the code would be similiar with prisma orm tests. The test for adding a blog needs the user to be logged in
I would show you the current project but it's still in planning phase and doesn't have relevant bits that make it integration test like login. Currently i basically have only one endpoint that fetches from one table
integration testing is when you test it before deploying to production, to make sure all the changes previously made are working with the existing system and data
yes, but that is not integration testing
that is an unit test
then locally fake an user
for that test
you can test the login and test the edit at the same time if you just fake whatever you need to fake to make it work
Hmmm i wonder why full stack open called it integration testing then? It's wrong then?
By faking a user is what I'm doing in the file I linked count?
The beforeEach manually inserts a user in the database so the api has a user already registered to perform login and edit?
or just use a non-sense user
for example, use the user id 1234 for anything related to editing
use the id 456 for anything related to inserting
this way, when you look into the database on an error, you see distinct ids
Alright gotcha
you can create the users, by the way
maybe even should, to avoid issues
but that is before you do the automated testing
when you seed the database
By seed you mean seed with test data?
yes
there is a point where you have to create all the database stuff, right?
Yeah.
at that point, create those users
Alright I got it. I'll follow the unit testing guide linked by prisma then
How do I mark this as resolved? Do I just react with ✅?
you have to add the "solved" tag
it's supposed to be the first one
alright did it. Couldn't find on the mobile menu
the mobile app is ... quirky