Unit Testing Private Function Through Public Interface

Question

Am new to unit testing, and I have been struggling with the right approach to test private functions. I have done my research, and am going with testing through the public interface.

My problem is the following, if I have a private function used by two public functions, I encounter test case duplicates, which I don't know how to overcome. Extracting the private function into another class doesn't seem appropriate in the case am facing, as the function is sufficient only for the class am using it from.

Example:

// This function is called only once, once the view is loaded
override func handleViewDidLoad() {
    super.handleViewDidLoad()
    loadData()
    // I have extra setup code in here
}

 // This function is called when user double taps on the screen
 override func handleReloadData() {
    super.handleReloadData()
    loadData()
}

private func loadData() {
    delegate.showLoading()
    fetchData { [weak self] in
        self?.delegate?.hideLoading()
    }
}

// I have another function that uses this one. But it's not included in the sample
private func fetchData(then completion: @escaping (() -> Void)) {
    service.start() { [weak self] (_, error) in
        if error == nil {
            if self?.shouldTrackScreen == false {
                self?.shouldTrackScreen = true
                self?.delegate?.trackScreen()
            }
        }
        completion()
    }
}

So when I think about handleViewDidLoad function's test cases. I will have the following:

1. Check that showLoading is called.
2. Check that hideLoading is called in case of service success.
3. Check that hideLoading is called in case of service failure.
4. Check that service.start() is called.

Same applies to handleReloadData test cases. This way I will end up with a duplicate of each test case of the above. And if I have another function that uses fetchData function, I will also have to repeat the 4th test case.

Is there a way to overcome those duplicates?

---

Edit

Sample test cases for clarification

1- handleViewDidLoad tests

func testHandleViewDidLoadCallsShowLoading() {
    // Given
    stubService(forAction: actionType)

    // When
    sut.handleViewDidLoad()

    // Then
    verify(mockDelegate, times(1)).showLoading()
}



func testHandleViewDidLoadCallsHideLoadingWhenServiceSucceeds() {
    // Given
    stubService(forAction: actionType)
    
    // When
    sut.handleViewDidLoad()
    
    // Then
    verify(mockDelegate, times(1)).hideLoading()
}

func testHandleViewDidLoadCallsHideLoadingWhenServiceFails() {
    // Given
    stubService(forAction: actionType, error: VFAppError())
    
    // When
    sut.handleViewDidLoad()
    
    // Then
    verify(mockDelegate, times(1)).hideLoading()
}

2- handleReloadData tests

  func testHandleReloadDataCallsShowLoading() {
    // Given
    stubService(forAction: actionType)
    
    // When
    sut.handleReloadData()
    
    // Then
    verify(mockDelegate, times(1)).showLoading()
}

func testHandleReloadDataCallsHideLoadingWhenServiceSucceeds() {
    // Given
    stubService(forAction: actionType)
    
    // When
    sut.handleReloadData()
    
    // Then
    verify(mockDelegate, times(1)).hideLoading()
}

func testHandleReloadDataCallsHideLoadingWhenServiceFails() {
    // Given
    stubService(forAction: actionType, error: Error())
    
    // When
    sut.handleReloadData()
    
    // Then
    verify(mockDelegate, times(1)).hideLoading()
}

and in the setup method that gets run before every test case I have this

override func setUp() {
    // Put setup code here. This method is called before the invocation of each test method in the class.
    super.setUp()
    
    sut = Presenter(viewController: mockDelegate, service: mockService)
    stubDelegate()
}

Answer 1

If I have a private function used by two public functions, I encounter test case duplicates

No you don’t.

I know people say the way to test a private function is through the public function that uses it. This is correct but it’s still the wrong way to think about it.

You don’t test “private functions”. You test ALL the code behind the public interface of the unit, the abstraction, the system under test (which might be a public function).

The fancy way to say “ALL the code” is code coverage. If what you’re testing uses a private function then your test better exercise it. Not because it’s a function. Because it’s part of what you’re testing.

If you’re worried that you’re exercising the same code twice stop it. The tests shouldn’t even know that. Unless this private function slows the system to a crawl you’re just micro optimizing. Don’t expect anyone to thank you for solving non problems.

It makes about as much sense to mock out the private function as it would to mock out a public library call like Math.abs(). So long as it’s timely, deterministic, and free of weird dependencies and side effects just think of it as part of the public function.

A test should never know about how a public function works. Just that it works. That way you decide if you use a private function or not. The test doesn’t get to have an opinion.

Answer 2

Here is a dead simple solution:

If you have several test cases which validate the same conditions or the same behaviour for different entry functions of the same object, refactor the duplicate assertion code into a common function.

In the afterwards given example, the member function of the sut which is called has to be a parameter of the extracted function. I don't know Swift, but I guess it has the necessary functional tools, so take this as pseudocode:

func testMySutFuncionCallsShowLoading( mySutFunction: ()->() ) {
    // Given
    stubService(forAction: actionType)
    
    // When
    mySutFunction()
    
    // Then
    verify(mockDelegate, times(1)).showLoading()
}

func testHandleReloadDataCallsShowLoading() {
    testMySutFuncionCallsShowLoading ( ()-> sut.handleReloadData())
}

func testHandleViewDidLoadCallsShowLoading() {
    testMySutFuncionCallsShowLoading ( ()-> sut.handleViewDidLoad())
}

The DRY principle is not only valid for production code, it can (and should) also be applied to testing code.

Note the described problem has not much to do with the fact that loadData is a private function, it stays the same when loadData would become public, or when loadData would be eliminated by copying its code directly into the calling methods.