3 ms·
I find that unit tests are much less useful than integration tests. When we write unit tests, we ask the person to write the code to spend a lot of work docume
by btilly 6y ago
I find that unit tests are much less useful than integration tests.
When we write unit tests, we ask the person to write the code to spend a lot of work documenting how they expect the system that they are integrating with to work. What happens when that system behaves differently? Or changes in the future? And the way that mocks are set up are very sensitive to implementation details, which is a maintenance burden when you have to change that.
As a simple example, I had a function that was loading data into a database with a series of insert statements. I sped it up by several orders of magnitude by using a COPY to send CSV data. Guess how well that worked with the mock database interface in the unit tests? (Long story short, it didn't. I replaced that unit test with an integration test.)
And yes, I've heard all of the lectures from test first folks. But somehow I've never had the experience of things working that way with my projects. (Possibly because most of what I do is close to the software/database interface.)
- mpweiher 6y agoIf it's talking to the database, it's not a unit test. https://blog.metaobject.com/2014/05/why-i-don-mock.html https://blog.metaobject.com/2014/05/why-i-don-mock.html
- btilly 6y agoI'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.