My question is not really RxSwift related but rather the usage of protocols in the book. I kinda understand protocol oriented programming from a functionality stand of view like it is explained in the protocol oriented programming tutorial. But I can’t figure out why TaskServiceType protocol is created in this chapter. It is briefly said in the book that this is a more “responsible” approach and helps on unit testing… Can someone explain to me why it is more “responsible”? And for testing, if we created a test-only TaskService class conforms to TaskServiceType, are we then would not be testing the actual TaskService class?
@peng90 when designing a “service” in your application (a part of the code that provides a internal APIs for a specific group of tasks with no user interface by itself), you want to be able to test it. Also, since an application typically has multiple services, you want to be able to individually mock each service, hence the reason I like to hide the implementation behind a protocol.
We didn’t have enough space in the last chapter to show everything, i.e. testing of the task service and a mock implementation (that doesn’t make sense in QuickTodo as there is only one service in this very simple application).
Mocking services makes it easy to test the application logic with predefined conditions.
Hope this explanation makes sense, let me know if you need more!
@fpillet Thanks for the explanation! So, is it correct that the mocked test services are for testing other components of an app that use the services? And there should still be test cases to test the actual “non-mocked” services? Thank you!!
@peng90 Absolutely, testing a non-mocked service is part of testing your application and its fundamental component. Sometimes you can have services that depend on other services (for example some logic service depends on a network service to perform requests and process stuff). You can mock the dependant services to isolate and test the service that you want to test.
Also, mocking a service can be useful in cases where you don’t have the actual implementation yet. Like when developing and app that uses a web API and the API is not ready yet, you can mock the results and keep developing your app.