-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Server Integration tests] Enrich integration GraphQL API tests #7526
Labels
Comments
Issue synced into GitStart. Please review, edit and hand it off to GitStart by following this link. |
This issue has been handed off to GitStart: https://clients.gitstart.com/twenty/5449/tickets/TWNTY-7526 |
charlesBochet
added a commit
that referenced
this issue
Oct 17, 2024
### Description - We are using gql instead of strings to be able to see the graphql code highlighted ### Demo ![](https://assets-service.gitstart.com/28455/d06016b9-c62c-4e0d-bb16-3d7dd42c5b6b.png) Fixes #7526 --------- Co-authored-by: gitstart-twenty <[email protected]> Co-authored-by: Charles Bochet <[email protected]> Co-authored-by: Charles Bochet <[email protected]>
charlesBochet
pushed a commit
that referenced
this issue
Oct 22, 2024
…7931) This PR was created by [GitStart](https://gitstart.com/) to address the requirements from this ticket: [TWNTY-7526](https://clients.gitstart.com/twenty/5449/tickets/TWNTY-7526). --- ### Description NoteTargets and MessageThreads are special cases because they do not have a notable property that we could use in "update" the test cases,\ for NoteTargets we are using the personId, testing the relation, but for MessageThreads we are using updatedAt. To test the relations for MessageThreads\ we would need to update another object (Message) because the relation is ONE_TO_MANY, updating another object in a test that would update the current tested object sounds incorrect.\ In the NoteTargets, we can update the NoteTarget object because the relation is MANY_TO_ONE\ for some tests we need an account ID, we are using Tim's account for all the tests (the token in jest-integration.config.ts), so we are using a constant to use the account ID ### Refs #7526 ### Demo ![](https://assets-service.gitstart.com/28455/7f1c520e-78e4-43c3-aa89-f6fc09e0a056.png) --------- Co-authored-by: gitstart-twenty <[email protected]> Co-authored-by: gitstart-twenty <[email protected]>
This was referenced Oct 22, 2024
charlesBochet
pushed a commit
that referenced
this issue
Oct 24, 2024
…7978) This PR was created by [GitStart](https://gitstart.com/) to address the requirements from this ticket: [TWNTY-7526](https://clients.gitstart.com/twenty/5449/tickets/TWNTY-7526). --- ### Description For workspace members, the deletion of multiple members is a special case that is not permitted by the method for regular users. As a result, we ensure that multiple deletions are not processed. For certain tests, both an account ID and a user ID are required. We are utilizing Tim's account for all testing purposes, as specified by the token in `jest-integration.config.ts`. To streamline this process, we have defined a constant to store and reference the account ID and user ID during testing.Refs #7526 ### Dem ![](https://assets-service.gitstart.com/16336/4df04650-70ff-4eb6-b43f-25edecc8e66f.png) Co-authored-by: gitstart-twenty <[email protected]>
charlesBochet
added a commit
that referenced
this issue
Oct 28, 2024
…8015) This PR was created by [GitStart](https://gitstart.com/) to address the requirements from this ticket: [TWNTY-7526](https://clients.gitstart.com/twenty/5449/tickets/TWNTY-7526). --- ### Description We are using standard field and object IDs because there is a problem when creating them as we would with helpers. We were creating custom objects and removing them in afterAll, but there is a problem that causes a conflict in the object IDs if the tests run at the same time. The solution would be to modify the test command as mentioned here: <typeorm/typeorm#6125> Currently, we are using the standard IDs but we can create the objects within the test if you want, but we would need to make them run in sequence ### Demo ![](https://assets-service.gitstart.com/16336/70c5550e-8570-45d7-a613-a3d6b79e7c00.png) ### Refs #7526 --------- Co-authored-by: gitstart-twenty <[email protected]> Co-authored-by: Charles Bochet <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Scope & Context
We have recently introduced integration testing suite on the server graphql API. See:
packages/twenty-server/test/companies.integration-spec.ts
We have 1 suite per standard object (company, person, note, ...) currently.
Right now, each of these testing suites are containing only 1 test testing the findManyRecords query.
What
We would like to enhance each of these testing suites to tests the API more extensively.
It is VERY important that a given testing suite does not have any side effect overall. This enforces that all suites keep being independant. Whatever a suite creates / modifies / delete should be reverted.
We propose the following testing strategy for each suite (ex: on company case). All these tests should use the GraphQL API and assert that the response is correct.
Start with companies.integration-spec.ts, then we can replicate for all other suites.
Note 1: Integration tests are high level tests, we don't want to test every edge cases. Ideal test filling as many fields as possible but there is no need to tests combinaisons.
Note 2: each of these integrations suites can get very long. We don't want to break this suite into multiple suites as the suites need to have no side effects. However, it would be great to split into multiple files (maybe extract the query / response to different fields) that will be called by the unique suite.
List of testing suites
Do:
Don't:
The text was updated successfully, but these errors were encountered: