3 ms·

I really don't get the debate. If you want to test state vs. behavior you still need to orchestrate and verify that state. You're still "mocking" because you'

I really don't get the debate. If you want to test state vs. behavior you still need to orchestrate and verify that state. You're still "mocking" because you're (presumably) not using a production system on which to test and you're using predictable, idempotent tests and test data. The only difference is you're not using a mocking "framework". Seems to me all you're doing is inheriting a lot of external dependencies that have little or nothing to do with your test. I don't see mocking as behavior vs. state, but rather just a way to remove dependencies that lead to brittle tests. What am I missing?

falcolas 12y ago
> you still need to orchestrate and verify that state. Only if you limit yourself to testing using unit tests. Two of the strongest testing tools care not one bit about internal state. Combinatorial testing tests all possible combinations of input pairs, and looks for the system to fail. Fuzz testing creates a fairly large volume of noise as input, and looks for the system to fail. Integration testing should be in your toolbox right alongside unit testing, and will exercise objects which are not appropriate for unit tests. > inheriting a lot of external dependencies that have little or nothing to do with your test. I've found that this kind of thinking leads to development practices which rely on unit tests & production as their sole methods of testing. If a component is part of your production system, it should also be part of your test system.