2 ms·
I'm aware of this. If it is talking to a database, it's not a unit test. If you've mocked out the database, it is a unit test. My point is that the unit test
by btilly 6y ago
I'm aware of this.
If it is talking to a database, it's not a unit test.
If you've mocked out the database, it is a unit test.
My point is that the unit test version is a lot of work to create and tends to be useless. (Which is similar to the point that your blog link made.)
- mpweiher 6y agoNo. Stubbing out the database does not turn a test into a unit test , it turns it into a stubbed-out integration test. (Mocking is something different) And since the point of an integration test is to test the integration, having a stubbed out version of that is fairly pointless, as you have discovered. If you create actual unit tests, and allow those to drive your design, you will find much more joy.
- bluntfang 6y agoIf you write your code in such a way where business logic and database access are separated you won't have to mock out the database. Business logic is where the Good Stuff is. We can trust that the database access package is working because we probably didn't write it and it probably has it's own set of tests.
- btilly 6y agoIf your business application deals with large volumes of data, trying to abstract out the database is a recipe for performance problems. Instead you want to push logic to the database. To give a real example, I'm working with time series generated by sensors on factory equipment. They can easily have millions of records per day.