We have recently started writing more unit tests and fewer integration tests with the understanding that unit tests allow us to detect bugs in a more focused way; Of course, this has a price because writing unit tests means we need to create lots of mocks and spent more time.
My question concerns database and repository tests:
Given that I have a repository (of todos for example) that performs simple CRUD operations in the database (almost no business logic), should I test it? And if so - what to do with the model in such a case? Am I creating a mock for it?
My application contains the following classic flow: Controller -> Service -> Repository -> DB.
I test this flow through an integration test where I perform an HTTP request to my controller and expect to eventually see "traffic" in the database (deletion, retrieval, creation, etc.).
Is it right to do that? And if so - is it better to use an in-memory database or a database for the TEST environment? Does that mean I have to use database seeding before the actions I test?
question from:
https://stackoverflow.com/questions/65517102/does-using-an-in-memory-database-seeders-in-an-integration-test-is-a-good-prac 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…