read

Real World Mocking in Swift by Veronica Ray:

OCMock has severe limitations in Swift
because Swift does not have reflection

If you are not using a DI framework
you can still manually inject dependencies

DI - simply means giving an object it’s instance variables

Constructor Injection -
have a default constructor with real ivar,
have convenience constructor with DI injected objects

Stubs - fake a method call

Mocking with protocols
is better than subclassing

What makes a good mock?

  • Quick and easy to write
  • Relatively short and does not contain much information you don’t need
  • Legitimate reason to not use real object

More value type,
less mocking needed

Related: Boundaries, Complexity

Partial mock an anti-pattern?

what is real? what is fake?

Partial mock decreases comprehensibility of tests

I disagree on this point too

I get wary every time I hear a pattern is anti-pattern
because a pattern is only anti because of the way you use it WRONGLY

Partial mock is usually subclassing the actual object
and override part of it so as to “mock” it

It is a simple way to achieve mocking

With Swift nested type
testing with partial mocks defined right in the test case
makes clear what is real, what is fake


Image

@samwize

¯\_(ツ)_/¯

Back to Home