4 ms·
> The point is: if your tests just assert which methods are called on dependencies with what arguments (or something close to that), they are extremely coupled
by Veuxdo 3y ago
> The point is: if your tests just assert which methods are called on dependencies with what arguments (or something close to that), they are extremely coupled and brittle.
I'll go further. These tests are worse than useless; they're harmful.
- They're the very definition of testing an implementation
- You will wasted a ton of time updating them when your implementation changes
- They give a false sense of security/productivity
- SAI_Peregrinus 3y agoSometimes they're still necessary. E.g. many devices need particular sequencing in their power-up between multiple rails. The Intel 82598 Ethernet Controller datasheet[1] page 129-132 shows this nicely. If you're writing a driver you have to test that the appropriate GPIO control calls happen in the right sequence (and with the right timings). Of course it's an implementation detail, different ethernet controllers have different power-up sequence requirements, and thus different drivers. Of course you don't want to have to use real hardware for these tests, especially because with some devices incorrect power-up sequencing can cause permanent damage. So you write mocks for the various hardware functions and test the driver with those, and use their counters & the test harness's logging to assert that the sequencing and timing is correct. [1] https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/82598-10-gbe-controller-datasheet.pdf https://www.intel.com/content/dam/www/public/us/en/documents...