On Thu, Sep 11, 2014 at 4:06 PM, Mark Ramm-Christensen (Canonical.com) <mark.ramm-christen...@canonical.com> wrote: > But they are not the ONLY reasons why they are valuable. > There are plenty of others -- performance, test-code cleanliness/re-use, > result granularity, etc.
Performance is the second reason Roger described, and I disagree that mocking code is cleaner.. these are two orthogonal properties, and it's actually pretty easy to have mocked code being extremely confusing and tightly bound to the implementation. It doesn't _have_ to be like that, but this is not a reason to use it. > Like any tools, developers can over-use, or mis-use them. But, if you > don't use them at all, That's not what Roger suggested either. A good conversation requires properly reflecting the position held by participants. > you often end up with what I call "the binary test suite" in which one > coding error somewhere creates massive test failures. A coding error that creates massive test failures is not a problem, in my experience using both heavily mocking and heavily non-mocking code bases. It rarely goes into the repository in the first place, because it's a massive breakage, and when it does go in due to differences in environment, it's easy to spot the root of the failure because proper code is layered. (...) > My belief is that you need both small, fast, targeted tests (call them unit > tests) and large, realistic, full-stack tests (call them integration tests) > and that we should have infrastructure support for both. Yep, but that's besides the point being made. You can do unit tests which are small, fast, and targeted, both with or without mocking, and without mocking they can be realistic, which is a good thing. If you haven't had a chance to see tests falsely passing with mocking, that's a good thing too.. you haven't abused mocking too much yet. gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
