Test Driven Upload method? - ios

Question

I'm in a situation where I'm trying to use Test Driven Development.
I've got no experienced in Swift, Xcode, Apple, IOS, TDD or even the macbook I'm using for development. Basically I'm a .Net Developer in a very unfamiliar situation.
My current problem arrises from my ignorance on how to make a unit test that test a void method.
I'm trying to make a method that sends a Image to a server.
But my issue here is that I do not know how to test a method that doesn't return a value.
I imagine that my method is going to be something similar to this:
public func Upload(_ image: UIImage)
and I imagine that I'll need to implement some version of URLSession that eventually will have to call a resume() method. but how do I test if this method is doing what it's supposed to be doing without invoking the network ? and after that how do I make an integration test where I can see that the expected result is in fact a file uploaded to the server ?
Currently the server will be on the computer I'm developing on but the actual software will run from a testIphone that I've been issued.
I've been searching online for days now and the best I've come across have been this link http://swiftdeveloperblog.com/image-upload-with-progress-bar-example-in-swift/
But it only approaches bits and pieces I imagine will be part of the solution not the testing of said solution.
I think it's important to add I'm very much against creating to much complexity for testing purposes. testing should be simple and straight forward.

Answer 1

The approach to take is to use a a test double to check that the correct networking calls are made by your upload method. You'll be making an asynchronous call to a networking library, which may be URLSession or may be another library such as AlamoFire. It shouldn't matter to your upload method which library is in use.
To achieve this, you want to avoid directly using URLSession, and use a wrapper which conforms to an interface that you can then mock in your tests. This means that your code will use a different implementation of the networking class at runtime than at test time, and you'll "inject" the correct one as required.
For example, you could have this interface to your networking library:
protocol NetworkRequesting {
func post(data: Data, url: URL)
}
With the following real implementation to be used at runtime:
struct NetworkRequester: NetworkRequesting {
func post(data: Data, url: URL) {
let session = URLSession()
let task = session.uploadTask(with: URLRequest(url: url), from: data)
task.resume()
}
}
However, at test time, you use the following mock instead:
class MockNetworkRequester: NetworkRequesting {
var didCallPost = false
var spyPostData: Data? = nil
var spyPostUrl: URL? = nil
func post(data: Data, url: URL) {
didCallPost = true
spyPostData = data
spyPostUrl = url
}
}
And then, given the following class under test:
class ImageUploader {
let networkRequester: NetworkRequesting
init(networkRequester: NetworkRequesting) {
self.networkRequester = networkRequester
}
func upload(image: UIImage, url: URL) {
}
}
You can test the implementation of upload like so:
class UploadImageTests: XCTestCase {
func test_uploadCallsPost() {
let mockNetworkRequester = MockNetworkRequester()
let uploader = ImageUploader(networkRequester: mockNetworkRequester)
uploader.upload(image: UIImage(), url: URL(string:"http://example.com")!)
XCTAssert(mockNetworkRequester.didCallPost)
}
}
Currently, that test will fail as upload does nothing, but if you put the following into the class under test, the test will pass:
func upload(image: UIImage, url: URL) {
guard let otherUrl = URL(string:"https://example.org") else { return }
networkRequester.post(data: Data(), url: otherUrl)
}
And that's your first TDD cycle. Clearly it's not yet behaving as you'd like, so you need to write another test to make sure that the url used is the one you expect, or the data passed is what you expect.
There are a number of ways to get your code to use the real network requester at runtime, you could have the init method use default parameter values to get it to use NetworkRequester, or use a static factory method to create it, and there are other options like Inversion of Control, which is well beyond the scope of this answer.
The important thing to remember is that you're testing that you make the correct calls to the networking framework, you're not testing the networking framework. I like to keep my protocol interfaces pretty declarative, passing the things required to make a request in any framework, but you might find you prefer to go closer to the metal and essentially mirror the implementation of URLSession - it's up to you, and more of an art than a science, in my opinion.