4 ms·
If you have 5 statements like "if err := doThing(); err != nil { return err }" then you need to simulate the success of all 5, success of the first 4 and failur
by closeparen 5y ago
If you have 5 statements like "if err := doThing(); err != nil { return err }" then you need to simulate the success of all 5, success of the first 4 and failure of the last, success of the first 3 and failure of the 4th, success of the first 2 and failure of the 3rd, etc.
- morelisp 5y agoFor a total of six cases to deal with. Not 15.
- closeparen 5y agoI said 15 mock expectations, not cases.
- morelisp 5y agoIf all five of those things also need to be independently mocked, you're mocking too much and your mocks suck.
- closeparen 5y agoIf they're not mocked it's an integration test. Integration tests are welcome as a supplement to unit tests, but unit tests are table stakes.
- morelisp 5y agoAn automated test suite is table stables. If you can achieve correct, maintainable code better with functional or integration tests than unit tests, you should. There is no hard technical line between "unit test" and "integration tests", it's a semantic question of how you define your units. Even if do you take a tiny, restrictive definition of your units, you could still use a fake or stub instead of a mock. https://martinfowler.com/articles/mocksArentStubs.html https://martinfowler.com/articles/mocksArentStubs.html To get very specific for Go, we use testify suites, tend to set up fully functional stubs in `SetUp`, and then test cases either use them to verify happy paths, or `s.BreakStep1()` in one test, `s.BreakStep2()` in the next, etc. So in this case we would write a total of five extra lines for the five possible ways to break.
- closeparen 5y agoI think that is a fair opinion and my life at work would be better if others shared that opinion. Go however does officially stake out the opposite position: coverage only "counts" if the test is in the same package as the unit under test.
- deleted 5y ago[deleted]