Jonathan Worthington — 45 minutes
If it ain't tested, it'll probably be broken. And if it ain't automated, it'll probably get done incorrectly on a Friday afternoon, just before home time.
I build and operate a number of Raku web applications, which are in turn backed by Postgres databases. And, to my shame, none of them had database integration tests, and deploying changes to the database involved connecting to the managed relational database instance and running a DDL query - which, given I write them maybe once a month, was liable to be a bit off. Meanwhile, in another project I work on that uses Node.js, we'd taken the time to set up some Docker thingy that let us run database tests, and were using a migrations library, and it was far nicer...but the migrations library was mostly a SQL DDL generator. I wondered if I could achieve better for my Raku projects.
In this presentation I'll describe my efforts, namely:
* `Test::ContainerizedService` - a module that uses container technology to set up a throw-away database instance that can be used for testing.
* `DB::Migration::Declare` - a module that provides a DSL for describing database migrations. While this does ultimately generate SQL, it builds up a working model of the database schema as it goes, meaning that it can detect a range of errors before one even gets to the point of trying to apply the migration.