| Where to Test Your Code The last 10-15 years in software development have seen a widespread embracing of unit testing. Before the popularity of mobile phones and their apps, most of the organizations I'd worked in gave lip service to automated unit testing, and often even more complex integration/system tests. These days, it seems more and more people embrace unit testing, and I hear about that often from customers and attendees at events. I don't often hear about more comprehensive integration and system testing, I found an interesting article from the Pragmatic Engineer that looked at how the Bluesky social network was built. The article is partially paywalled, but I have subscribed because of the interesting thoughts they publish. In this article, there was a really interesting part of the article on testing. This is a section titled "Integration tests over unit tests". This isn't described in any detail, but there is a note that the priority is for integration tests. There are unit tests, but I'm guessing this means that they write mostly integration tests first and then perhaps fill in with unit tests. The article does note that the backend is heavy on integration tests, looking to test the flow of data through the network. I assume network means their application here. I think a lot of companies think about skipping unit testing in the database and instead might run some sort of integration tests from the application that hit the database. At least, I hope they do this. If they use unit tests that mock the database, that's not necessarily a great way to ensure that the things in the database work as expected. Data types, defaults, rules/constraints, etc. All of these things might be different in a database over time, which is why devs need a database that is regularly updated from production (though is likely smaller in dataset size). I can see some value in looking at integration tests more than unit tests. If we can only test so much because of time pressures, ensuring that the flow of read/write to and from the database makes sense. Queries as well, since potentially there are writes that store data and queries that read or aggregate data that might be transformed somehow in the database. Imagine writing a field, but having queries that read from a computed column that has normalized the data somehow. Or even triggers that have changed the data. I am a bit fan of testing, and I think there is value in database unit testing, but I also understand that many people struggled to get started there. If you aren't going to do database unit testing, then ensure that you are running integration tests that call through to a database. I realize this can be a hassle to set up in a pipeline but building better quality software means some investment in automated testing. That requires a way to build and update dev/test databases over time. A crucial part of embracing DevOps in the database. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums | 
