APIと異なり、モデルという名のリソースを横断して、縦横無尽にクエリを連発することができます。なったとき気を使わなければならないのは、rspecの書きっぷりではないでしょうか。RESTでは各々のリソース毎にCURDをベースとして、contextとletを組み合わせることで、比較的綺麗に試験を記述することができました。paramsもhashを利用して、割と簡潔にletを繋げていけたことと思います。GraphQLではJSONっぽいqueryをヒアドキュメントでゴリゴリと書いて、みたいな作業が求められます。specファイルは長く冗長となり、なんかもう試験とか面倒臭いんだけど、といった気分になってしまいます。実装requestに利用するqueryを外部にerbファイルとして書き出します。場所はspec/gqlsとか、適当にディレクトリを掘ることにしましょう。そこにpost.gql.erbといった具合にファイルを用意して、GraphQLのクエリを記述します。フロントで利用しているGraphQLのクエリをそのまま持ってくるイメージでございます。clientを利用している場合は、.gqlファイルを利用していると思いますので、それをコピペです。specから呼び出すようにします。すると、比較的簡潔にspecファイル上で、GraphQLのリクエストを表現することができます。今回はfetchなクエリを投げておりますが、gqlファイルを別に用意することで、mutationについても同じように試験することができます。いう疑問は、まったくもってその通りでございます。したら、使う時が来るかも、みたいな気分でerbにしてみました。.gqlのまま読み出しても何ら問題はございません。