How to test 2 methods with common logic?

Question

Let\'s say that I have 2 public methods:

func didSelect(data: Data) {
    // do something

    self.view.showText(textForData(data))
}

func didDismiss(data: Dat         


        

Answer 1

I think that the formatting of the data is an own responsibility. So you should extract it to its own class.

This class could be unit tested on its own.

Your other class(es) that use this one should be decoupled by using an interface instead of the class directly. The dependancy should be injected (for example in the constrcutor). You could write an default constructor creating the default class to simplify things in production code (poor mens dependency injection).

Then you could mock the formatter and test the other class(es) in isolation, verifying that the textForData method is called correctly.

Answer 2

You have a few options here.

1. Don't test textForData
2. Duplicate the behaviour in each test of the public method that uses it
3. Make textForData public
4. Make a public class for textForData

Point 1 and 2 are undesirable.

You seem oddly against point 3, but there are benefits to doing this. You will be able to test this behaviour once, given you really care about doing so. I don't know Swift, but in other languages this isn't as bad as it seems. The general advice is to code against and interface, rather than an implementation. So the public interface of this class would have didSelect and didDismiss. Your production code would be expressed in terms of this interface, meaning even though textForData is a public method on the class you cannot access it directly.

The good news here is that your tests can be written against an implementation (in fact, they have to) so here you'll have access to all three methods. So you can test to your hearts content.

Point 4 is similar to point 3, but stored as a separate class. I'd opt for this given that you could argue we have broken the Single Responsibility Principle in point 3. To hide this I'd make a nested class to begin with given you state this code is only used within this one example. Again, your tests will have access to this using the same ideas as above.

You're code is moving towards embracing composition, therefore you should embrace the benefits such as small classes, well factored code and more.