Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Don't listen to dogmas too much. Go for the simplest thing that could possibly work, also for tests. (Disclaimer: I do know TDD, but I don't know Objective C).</p> <p>To let <code>SieveClient</code> create its <code>SaslConn</code>'s in production code, but use mock ones in tests, you can use <a href="http://en.wikipedia.org/wiki/Dependency_injection" rel="nofollow noreferrer">dependency injection</a>. Add a setter method to <code>SieveClient</code> to pass in a <a href="http://en.wikipedia.org/wiki/Factory_%28software_concept%29" rel="nofollow noreferrer">factory</a> (as an object or a function, depending on what Objective C permits), which <code>SieveClient</code> will use to make its <code>SaslConn</code>'s, instead of making them by itself. The test code provides a test factory that dishes out mocks. The production-case code for making <code>SaslConn</code>'s either moves to another factory to be unit-tested independently, or if it's too simple to break, remains as the default behavior inside <code>SieveClient</code> when the factory setter is not called.</p> <p>The simplest way to test network client code is by far to <a href="http://discuss.joelonsoftware.com/default.asp?joel.3.694492.26" rel="nofollow noreferrer">implement or re-use a mock server</a>. Don't mock out the gory socket details in <code>SaslConn</code>; instead, write an SASL server in your tests. The fact that your <code>SaslConn</code> can talk to it goes a long way towards providing testing for that mock server; in other words, <code>SaslConn</code> and the mock server are each other's unit tests. (Yeah, not "unit" in the purist sense, but nobody cares.)</p> <p>Finally, I have mixed feelings about the precept that hard to test code is badly designed. It depends. You should design your code so that it's easy to use (in caller code) and easy to modify. Unit tests are but a means to these ends: they are the first caller code that you will write, and they give you confidence that you don't screw up when making changes. Don't let a particular framework or methodology <a href="http://discuss.joelonsoftware.com/default.asp?joel.3.219431" rel="nofollow noreferrer">twist and maim your design</a> to the point of outweighing the benefits of TDD. In particular, expectation-based mocking frameworks such as OCMock make it way too easy to <a href="http://mindinthewater.blogspot.com/2010/02/mocking-frameworks-stubs-vs-mocks.html" rel="nofollow noreferrer">write brittle tests</a> that go like "I expect method <code>foo</code> to be called 3 times, and only then method <code>bar</code> to be called with exactly such and such arguments". Rather than using the wrong tools for the job, write your own!</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

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