CODEWITHSUNDEEP
iosunit-testingswifttdd
Rodrigo Ruiz
Rodrigo Ruiz

Reputation: 4355

How to test 2 methods with common logic?

Let's say that I have 2 public methods:

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

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

func didDismiss(data: Data) {
    if data.isSomething {
        self.view.showText(textForData(data))
    }

    ...
}

private func textForData(data: Data): String {
    var text: String

    if data.distance == nil {
        text = "..."
    } else if data.distance < 1000 {
        text = "\(data.distance) m"
    } else {
        text = "\(data.distance / 1000) km"
    }

    return text
}

Both of them depend on the formatting logic of textForData.

textForData has (with this minimized implementation) 3 possible cases. If I do test every possible case for both of my public functions, I'll end up with 6 test methods, and 3 of them would also be testing the same logic that was already tested by the other 3.

What's the proper way of testing this?

Ps.: I could write a separate test for textForData and in the tests for the public methods I assert that the textForData is called, but that seems to break the encapsulation of my class and I don't want to make the testForData public. I also wouldn't like to make a separate class just for my textForData logic, because I would end up creating too many dependencies for this current class, and that logic doesn't seem to fit anywhere else besides in this class.

Upvotes: 2

Views: 293

Answers (3)

MoJony
MoJony

Reputation: 116

Testing tends to bring out faults in code, if I understand you correctly you want to test 3 things.

the logic of your 2 functions using textForData and textForData itself. This means that testing textForData already covers most of your goal.

and then you just need to test the logic of the two other functions outside of the part that relies on textForData I see making it public as the best solution here, do you have a reason why you are opposed to it?

Upvotes: 0

Finglas
Finglas

Reputation: 15709

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.

Upvotes: 2

Holger Thiemann
Holger Thiemann

Reputation: 1082

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.

Upvotes: 1

Related Questions