At the moment it’s pretty common to have following setup for local development- docker-compose simulation production setup with application, database and all other containers needed to run the app- sometimes even with nginx. This is a good pattern to have local setup as close to production as possible. However, running unit/integration tests in this case may be just slow- slowest part of testing is communication with DB and usually it’s avoided by testing with in-memory sqlite. What if you can’t use in-memory sqlite database because you’re tied to database specific functions? You can mock your tests to avoid any DB usage and this is the most performant way but also forces you not to test anything that is returned by database- so integration tests can’t be really run this way.
When developing customer facing web applications usually you want to have some unique id for each object. By default django uses integer ID that is autoincremented by the database. However sometimes you want to expose this ID to your customer but you don’t want to expose how many objects of this type are there in your DB. Imagine case of e-commerce that want to show order number to customer but doesn’t want to reveal amount of orders to everyone in the world(especially competition). There are a few ways to accomplish that: