3 ms·

It's all about staying in language though, at least in my opinion. The test suite I don't run is the one that requires the complicated docker compose stack and

by XorNot 3y ago

It's all about staying in language though, at least in my opinion. The test suite I don't run is the one that requires the complicated docker compose stack and the local network to look just right. The test suite I do run is the one where I hit "run" in my IDE and then it lets be jump to what failed and debug seconds later. That, IMO, is what mocking is about: making the tests fast and easy to run so they actually are.

brianmcc 3y ago
Agree. Mocking is a slippery slope I think. We need to mock, for example, DownstreamAPI01 that our app POSTS to and GETs from, so we can put in accurate and realistic faked responses. We don't strictly need to mock other bits of our own apps - but many people choose to do so. Martin Fowler writes very well about this, and I hadn't even appreciated the "split" between sociable unit tests and solitary tests: https://martinfowler.com/bliki/UnitTest.html https://martinfowler.com/bliki/UnitTest.html I can see the appeal of both sides, but (a) I prefer sociable tests as they tend to test real code more than artificial constructs, and (b) people tend to get into a mess when they try to produce pure solitary tests, leading to the "not really testing your app" example in my earlier comment.
- StackOverlord 3y ago
  95% of unit tests will bring 5% of value and 5% of unit tests will bring 95% of value. Most unit tests should be handled at the integration level.
MoreQARespect 3y ago
The compose stack tests (when engineered right), are the only ones which can reliably reproduce and test almost any bug or feature reliably. In 2018 I could understand the aversion to them given how unbearably slow and flaky they could be but those problems are draining away with improved tooling and faster machines. I think before long they'll be the default - a test that is 4 seconds slower and 30% more realistic will seem like a no brainer.
time0ut 3y ago
I have both. 90% of my tests are normal unit tests that use mocks or fakes as needed to test the things I care about. 9% are integration type tests that validate broad behaviors with my app’s direct dependencies in an ephemeral environment managed via docker compose (usually anyway). 1% is a couple end to end tests that validate the whole system at deploy time and beyond.

by XorNot 3y ago

brianmcc 3y ago

Agree. Mocking is a slippery slope I think. We need to mock, for example, DownstreamAPI01 that our app POSTS to and GETs from, so we can put in accurate and realistic faked responses. We don't strictly need to mock other bits of our own apps - but many people choose to do so. Martin Fowler writes very well about this, and I hadn't even appreciated the "split" between sociable unit tests and solitary tests: https://martinfowler.com/bliki/UnitTest.html https://martinfowler.com/bliki/UnitTest.html I can see the appeal of both sides, but (a) I prefer sociable tests as they tend to test real code more than artificial constructs, and (b) people tend to get into a mess when they try to produce pure solitary tests, leading to the "not really testing your app" example in my earlier comment.

StackOverlord 3y ago
95% of unit tests will bring 5% of value and 5% of unit tests will bring 95% of value. Most unit tests should be handled at the integration level.

MoreQARespect 3y ago

The compose stack tests (when engineered right), are the only ones which can reliably reproduce and test almost any bug or feature reliably. In 2018 I could understand the aversion to them given how unbearably slow and flaky they could be but those problems are draining away with improved tooling and faster machines. I think before long they'll be the default - a test that is 4 seconds slower and 30% more realistic will seem like a no brainer.

time0ut 3y ago

I have both. 90% of my tests are normal unit tests that use mocks or fakes as needed to test the things I care about. 9% are integration type tests that validate broad behaviors with my app’s direct dependencies in an ephemeral environment managed via docker compose (usually anyway). 1% is a couple end to end tests that validate the whole system at deploy time and beyond.