Integration tests state setup

[naz]

The bigger the test suite for integration tests becomes, the harder it's to achieve a certain state for a test case. Opening this issue as a ground for discussion on how things could be improved.

As an example, checking if a certain record belongs to a specific relational filter takes to look up:

1. posts collection in base.json,
2. compare it with records in many-to-many.json
3. go back to base.json and check tags collection there

When there are multiple records/properties matching this 3 step process becomes over cumbersome.

One of the thoughts around making things easier to check would be not having a global state like base.json but a set of helper functions that would set up the state in few steps. The downside of this approach is more work in the test case setup, but than it's a lot more clear which cases are being expected to be returned. Hard to find a good middle ground here 🤷‍♂️

Don't have any specific recepie and current approach is good enough :) Just opening this issue as a discussion to try improve future test suite maintenance and development.

[ErisDS]

I don't really understand why the same posts, tags and users are being redefined in some of the files, or why other fixture files exist but are empty.

Seems like the original concept got misused, but I also see that all the code to have naming logic for each test suite got ripped out.

[naz]

@ErisDS atm, the empty files are: one-to-one and one-to-many relations fixtures. They are empty as we don't have any support for those relations just yet and will be filled out as we need them. As for 'many-to-many-extended' fixture redefining state, it hasn't been worked on and I did misunderstand it's usage in the beginning, will clean that up.

Seems like the original concept got misused, but I also see that all the code to have naming logic for each test suite got ripped out.

Which part are you referring to exactly?

[ErisDS]

This commit results in quite a change to the idea behind the test framework that was in place to start with:

TryGhost/mongo-knex@2e7777b

[kirrg001]

I think the test env is fine as it is? We define resources in base.json and add relations in a separate file. Resources don't need to be duplicated. I agree to your point that you have to have two files open to compare which resource has which relations, buuut for me personally speaking, this is nothing which annoys or annoyed me 🙂

There are for sure ideas/improvements we can add to any test env we have 👻I am not sure it's worth leaving this issue open? 🤔 I doubt somebody will have time to optimise the test env 🤓 What i experienced in the past: most of the time test env improvements happen natuarly. If you need them, you add them. If something sucks while you write tests, you change it.

@gargol feel free to either leave the issue open or close 🤘🏽

The only thing we could do quickly is to remove the empty fixture files e.g. https://github.com/NexesJS/mongo-knex/blob/master/test/integration/suite1/fixtures/one-to-many.json? 🤔 This is maybe a little bit confusing. These test cases are anyway not supported and skipped.

Seems like the original concept got misused, but I also see that all the code to have naming logic for each test suite got ripped out.

All of the original test env is still in place, except of the smart file name detection. When i was trying to get the tests fully working i had trouble working with it.