My first intent was to just have one local sqlite test db that would get reset to empty state before the tests run (EnsureDeleted+EnsureCreated), and then they all run concurrently on it. It sounded simple to setup and simple enough for my small crud app that only had a few tests.
My second intent was for the framework to create a new in-memory sqlite db for each test so I could fix the problem with tests failing when I'd run all of them at the same time, presumably because they all referenced the same db.
I am currently trying to complicate my life further in the hopes it helps with this by using a postgres database instead, and then in the IntegrationTests project I'm using TestContainers to get a PostgreSqlContainer. I am currently suffering because of some change I made so my tests aren't even being found anymore now, despite being listed in the test explorer when I run them I get "Test discovery finished: 0 Tests found" in output. Honestly I think I'm just gonna give up integration testing like this, it's been a complete waste of time so far.
Dunno what else I could say about my project that is relevant, it's a standard webapp crud with 2 controllers and the integration tests projects has facts like this. Very basic stuff I'd say. Unit tests are a separate project and will just be for simple method checks, no mocking (or at least as little as possible)
You are probably right and I just misunderstood fixtures / collections and how they work. I am now trying to configure it using postgres testcontainers and just letting each test create its own but facing a bunch of other issues so not even sure how this works anymore, seems like every tutorial has a different approach. Some just put all the code for creating containers in the setup/dispose of the test class itself instead of trying to be smart with the WebApplicationFactory fixtures and maybe I just end up doing that