Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Don't go down the dark path Master Luke. :) Don't mock everything. You could but you shouldn't... here's why.</p> <ul> <li>If you continue to test each method in isolation, you have surprises and work cut out for you when you bring them all together ala the <strong>BIG BANG</strong>. We build objects so that they can work together to solve a bigger problem.. By themselves they are insignificant. You <strong>need to know if all the collaborators are working as expected</strong>.</li> <li>Mocks <strong>make tests brittle</strong> by introducing duplication - Yes I know that sounds alarming. For every mock expect you setup, there are n places where your method signature exists. The actual code and your mock expectations (in multiple tests). Changing actual code is easier... updating all the mock expectations is tedious. </li> <li>Your <strong>test is now privy to insider implementation information</strong>. So your test depends on how you chose to implement the solution... bad. Tests should be a independent spec that can be met by multiple solutions. I should have the freedom to just press delete on a block of code and reimplement <strong>without</strong> having to rewrite the test suite.. coz the requirements still stay the same.</li> </ul> <p>To close, I'll say "If it quacks like a duck, walks like a duck, then it probably is a duck" - If it feels wrong.. it probably is. *Use mocks to abstract out problem children like IO operations, databases, third party components and the like.. Like salt, some of it is necessary.. too much and :x *<br> This is the holy war of State based vs Iteraction based testing.. Googling will give you deeper insight.</p> <p>Clarification: I'm hitting some resistance w.r.t. integration tests here :) So to clarify my stand.. </p> <ul> <li>Mocks do not figure in the 'Acceptance tests'/Integration realm. You'll only find them in the Unit Testing world.. and that is my focus here.</li> <li>Acceptance tests are different and are <strong>very much</strong> needed - not belittling them. But Unit tests and Acceptance tests are different and should be kept different.</li> <li>All collaborators within a component or package do not need to be isolated from each other.. Like micro-optimization that is Overkill. They exist to solve a problem <strong>together</strong>.. cohesion. </li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload