Add the "Decouple the back-end and front-end test through Contract Testing" chapter #40
Conversation
|
|
||
| ### One Paragraph Explainer | ||
|
|
||
| E2E tests do not scale well for hig applications, with thousands of user flows. Things get even worse if the UI E2E tests are used to test the server too because the result is hundred of slow and coupled tests. In Hasura, an internal working group proposed to decouple the back-end and front-end tests. |
There was a problem hiding this comment.
typo "hig applications"
|
|
||
| I (a Front-end engineer, keep it in mind) recently championed an initiative aimed at reducing Hasura's CI pipeline duration and the dependence on not-scaling-well E2E tests. | ||
|
|
||
| The problem is that **the Server team defensively uses the Hasura Console's** (the main UI of the company) **E2E tests** to check for regressions. If the Console works as expected, the Server works as expected as a by-product. |
There was a problem hiding this comment.
lol... so why don't they have api e2e tests?
There was a problem hiding this comment.
I don't fully get the layman's takeaway from this article.
At a high level, this sounds like we are running some e2e tests, they are recroding fixtures (which in this context are called contracts), and future tests are made into UI-integration tests. Is this correct?
E2e recording to fixutres is a decent idea. Where can someone not in Hasura find out more about doing something similar?
How about alternatives? Why doesn't the company use API e2e tests, instead of UI e2e, or UI integration?
Have you considered Pact? What did you find out, why isn't it a good fit?
I kind of wish to see this kind of analysis at the end, and recommendation for a layman to take some ideas away. Otherwise it's a good story, but does not help the reader as much as I wish it did.
I agree, let me close this PR and come back on this topic in the future with more examples and suggestions, if any 😊 |
Bring @NoriSte's article to the repo.