3 ms·
That doesn't really sound like an indictment of unit tests. I don't really understand why someone would meticulously write a bunch of unit tests and then wait t
by ad_fontes 2mo ago
That doesn't really sound like an indictment of unit tests. I don't really understand why someone would meticulously write a bunch of unit tests and then wait to prove them on a production deploy?
Unit and integration tests serve different purposes and one isn't necessarily better than the other.
- simonw 2mo agoIt's an indictment of writing only unit tests. If the system also had integration tests this would likely have been caught, but even more important is the lesson that no amount of automated tests is an excuse not to actually try using your software yourself.
- perrygeo 2mo ago> Unit and integration tests serve different purposes and one isn't necessarily better than the other. If they serve different purposes, then one is by definition better than the other, given the circumstances. There's a whole class of applications containing very little pure logic; dumb pipes hooking together a database and client over a network. It's a categorical mistake to fully unit test these. There are only a few "units" to test; everything else is a side-effect (disk, network, etc). Yeah you can mock. My point is that mocks do not cover real world behavior, so those types of apps require an integration/e2e heavy set of tests. Conversely, if you've got a logic-heavy library, you need unit tests. You can't rely on the behavior as filtered through the application. Different purposes. But depending on what world you're working in, one is definitely better than the other.