3 ms·
"mandating method call order and call count)" - Very few people use mocks like that. Most people use them glorified stubs for returning data. Personally these
by UK-AL 9y ago
"mandating method call order and call count)" - Very few people use mocks like that.
Most people use them glorified stubs for returning data. Personally these days I just in memory datastores.
- barrkel 9y agoI have seldom seen a jMock Expectations clause without oneOf etc.
- cjsuk 9y agoWe do use mocks like that. How else do you test that a complex piece of logic doesn't try and perform the same operation twice, such as a trivial case of sending only one message to a queue? Without the assertion, you are left with an assumption, which from experience isn't reliable and keeps you up at night.
- UK-AL 9y agoBecause it makes refactoring very difficult. One of the original intentions of TDD and Unit testing was to make refactoring much easier. If you start testing the internals of function, it makes it very difficult to refactor without breaking tons and tons tests. We only test on publicly exposed functions, and check the changes on the data or external services. It means we can do major refactoring's of internals, keep public functions the same but tests will still pass. One of the biggest mistakes that happened was that kent beck was misinterpreted and Unit was considered a code unit, when really it means a unit of behaviour.
- lolive 9y agoI don't disagree with your explanation. But the core point of objects is to bind a state and some method implementations. Mocking the state sounds mandatory to test the method implementations in such a paradigm. What you propose seems more like functional programming oriented testing.
- jononor 9y agoSome alternatives: - Make it possible to introspect the state and effects of the code on your dependency in the real implementation, and use that instead of a mock. Can then put the assertion into the code (a post-condition, design-by-contracts style) so it always runs, not just for the few explicitly written unit-tests. Those unit tests can be deleted in favor of something that tests something useful, like running the logic on - Return the effect (messages to be sent) instead of doing it internally as a side-effect. Then introspect and verify this data in the test. The dependency on the message queue can now be elimitated, both in test and by the complex piece of logic