What is a problem?

In my current team, there are 5 back-end developers and they all work in parallel. We faced a few problems on our way to building an app:

When someone changes a schema our front-end breaks down.

When someone changes resolvers out front-end breaks down.

To solve those problems I decided to cover this corner cases by tests as much as possible and this is what I ended up with.

When the schema is changed I want to be sure that these four cases are tested:

When a field is deleted.

When a field is renamed.

When a field is added.

When resolvers functions are changed I want to be sure that data I didn’t change is the same as I got before.

It is very similar to snapshot testing. I don’t check specific fields or lengths or structure. I only check what I get now and what I got before. The only difference, I write snapshots myself. It’s possible to delegate this job to a graphql server, but in my case, it’s ok to do it manually.

What does it give to me? At least I can see that someone’s changes broke something else. I run this kind of tests in two environments: locally and in CI. When I run it locally I see what my changes are and what they broke or did not. When CI runs it our team gets errors in a slack channel if there are any.