3 ms·
> But how do you deal with refactoring? We solved this problem by having thorough automated test coverage for all SQL queries. Here's basic lifecycle of a tes
by dansomething 5y ago
> But how do you deal with refactoring?
We solved this problem by having thorough automated test coverage for all SQL queries.
Here's basic lifecycle of a test:
1) Create the test database
2) Migrate the database to the latest schema version
3) Insert test data
4) Execute the SQL query
5) Validate the results of the query
- hu3 5y agoTests are nice. But I see disadvantages with relying on them: 1) We now need 100% test coverage for queries. Forget one of them and the castle might fall on the client side. This can be mitigated with gatekeepers on CI/CD pipeline to ensure 100% coverage. But it's still quite the effort. 2) Our feedback loop for developing refactoring is now slower now since we need to run all tests to see what broke after a schema change. In contrast to an IDE giving compilation errors. 3) If we build SQL queries by composing them, which is common pattern for business rule validations, there will be many branches to be tested. 4) We won't have auto-completion of table and column names in the IDE. And if you mistype them your feedback is slower. I say that as someone who went all in SQL query builders and composability in a project but when it grew large we were still afraid of changing schema despite having a very high test coverage.