4 ms·
The unit test story is indeed bizarre. Done right unit tests should test the unit, and you'll never hit these problems. The villians here were monstrous test f
by spopejoy 4y ago
The unit test story is indeed bizarre. Done right unit tests should test the unit, and you'll never hit these problems.
The villians here were monstrous test fixtures instead of mocks, "testing the fixture" instead of testing the code. Both were agency trading systems so "platforms" of a sort that needed significant refactoring to mock properly, so instead tests had to inject essentially fake concrete services.
Somehow I joined teams twice in my career that were trapped under this (who both indeed had "huge problems with their development practices") as their only coverage. The only way out is to write all new unit tests.
- fijiaarone 4y agoMocks are the personification of bad data. The only meaningful measurement derived from tests with mocks is how bad the architecture is.
- spopejoy 4y agoI don't know what you're criticizing here. I was contrasting "mocks" and "fixtures" in the context of unit tests as ways to instrument services depended on by the code under test. A "mock" in this paradigm is some kind of testing technology that allows you to directly instrument return values for function calls on the dependent service, whereas a "fixture" is some concrete test-only thing you coded up to use in your tests. If a fixture just acts as a dummy return-value provider, no problem (but you probably should have used a mocking solution). The problem that arises is fixture code that simulates some or all of the production service code, and/or (even worse) allowing modification of production code to allow use as a test fixture. This is the way to madness.