Initial tests coverage includes ensuring that all implemented entities are correctly written to the underlying PostgreSQL database. They exercise the graphql API in the test and make expectations against results of SQL queries.
If corresponding test gql queries are already available (eventually we want gql test queries for everything), tests ensure that they return the expected results as well.
Proposal
Currently, the postgres service is exposing it's default port on the host OS, which would allow us to run our tests from the host. However, as this is repository is a npm/yarn package and already depends on docker for development and testing, I think it would be more appropriate to run the tests in an additional service in the docker-compose.yml. Such a service could access the repo via a volume, would already have all necessary dependencies (i.e. python and friends) installed, and would have network access to (and DNS resolution for) other docker services in the composition. (use docker-compose.override.yml to expose necessary services / networks)
For making assertions about postgres data, I think the path of least resistance might be to use something like psycopg3 with SQL queries for the time being. This has the potential to make our e2e tests brittle with respect to Subquery's DB schema generation; however, I would expect a changes in the schema generation methodology to be infrequent and to come with a major version increment and due notice.
For graphql queries, after a brief search, I've discovered gql (available on PyPI).
Acceptance Criteria
Initial tests coverage includes ensuring that all implemented entities are correctly written to the underlying PostgreSQL database. They exercise the graphql API in the test and make expectations against results of SQL queries.
If corresponding test gql queries are already available (eventually we want gql test queries for everything), tests ensure that they return the expected results as well.
Proposal
Currently, the postgres service is exposing it's default port on the host OS, which would allow us to run our tests from the host.
However, as this is repository is a npm/yarn package and already depends on docker for development and testing, I think it would be more appropriate to run the tests in an additional service in the docker-compose.yml. Such a service could access the repo via a volume, would already have all necessary dependencies (i.e. python and friends) installed, and would have network access to (and DNS resolution for) other docker services in the composition.(use docker-compose.override.yml to expose necessary services / networks)For making assertions about postgres data, I think the path of least resistance might be to use something like psycopg3 with SQL queries for the time being. This has the potential to make our e2e tests brittle with respect to Subquery's DB schema generation; however, I would expect a changes in the schema generation methodology to be infrequent and to come with a major version increment and due notice.
For graphql queries, after a brief search, I've discovered gql (available on PyPI).