Testing Strategy

[opendoor]

Testing Strategy

[ethanpailes]

I haven't really looked for a database testing framework, though I hear sqlite has 300% code coverage, so maybe I should look at how their tests are set up.

I was planning on fleshing out the testing story by writing some failure tests to cover the error cases, testing against multiple postgres versions in ci, and writing more unit tests.

I especially think testing will be important for ensuring the correctness of the association code once that gets more fleshed out. My guess is that could get decently hairy because of cyclic data structures and whatnot.

In terms of automation and fuzz testing it might be cool to try to automatically generate database schemas and assert certain properties about them. That sounds like a pretty big undertaking though. I guess we could try to see if we could hook up go-fuzz to the schema generator in order to fully explore the code paths in pggen.

[ethanpailes]

I have now written some cli testing infrastructure which does a pretty good job of allowing us to write tests for error conditions that the code generator could run into.

That means the main outstanding thing for this issue is to test against multiple postgres versions. Docker should help with that.

[ethanpailes]

Closing in favor of #14 which is more focused