iOS Unit Test Mocking Tutorial

My full length Udemy course: Saving Data in Your iOS App Using Core Data: bit.ly/30dcIjA
Check out my new full length iOS course:
Saving Data using Core Data: skl.sh/2O23FMN
#swift #codepro #XCUnitTest #mocking #testing #OnPatreon #iOSProgramming
In this tutorial we will figure out a solution for how to mock a network service api client in our app so that we can simulate web service responses for web service APIs that might not be completely built yet.
-
50% off iOS Development Fundamentals Course on Udemy:
Udemy: bit.ly/2JfXdyn
or use CODEPRO999 for 50% off the course price.
Skillshare: skl.sh/2GgUwOL
-
Useful Learning Resources
iOS Programming Guide: amzn.to/2H3gqCq
Beginner's Guide to iOS Development: amzn.to/2snniaw
-
Check out some of the apps I've built:
itunes.apple.c...
itunes.apple.c...
itunes.apple.c...
itunes.apple.c...
-
Follow Code Pro on:
Twitter: / codepro7
Patreon: / codepro
Facebook: / thecodepro
If you found this tutorial helpful please like the video, share the video, and subscribe to CodePro. You can follow CodePro on Twitter, Facebook, for the latest channel news and updates.

[@CodePro]

Once you know the API contract of your web services you are good to go and can build your whole networking layer without the need for fully completed services. If the web service team introduces a bug or changes the service contract, more than likely, your unit tests will catch that as some of them may start to fail and you can report that to the web services team. If you want a good iOS beginners course you can use this link: www.udemy.com/build-your-first-ios-app-in-swift/?couponCode=CODEPRO999 to get my course for 50% off.

[@princepushkraj]

One of the best video I seen regarding API Mocking :) Kudos to all your efforts, you made it look very simple using step by step explanation.

[@brandonb6175]

This is the best video I have seen on testing on KZbin! Great work, and thank you!

[@CodePro]

Thanks!

[@manarabdelbasetmohamed8590]

perfect video about mocking and network testing

[@dhavalnena7386]

Great video so far explaining Mock and Stub! Thanks much!

[@Ravikanth_007]

Thanks you very much for the course , its very usefull , can you share the download link for the completed source code . Thanks.

[@kelvinfok]

I have a working client side example - github.com/kelvinfok/ios-unit-testing-mock based on the video

[@muralitharang1125]

Great Explanation. Thanks mate.

[@yourmovies3724]

This is an excellent video. Thank you for posting.

[@srbalan1995]

Thanks for this. Great video and please keep it up! 🥳

[@narmir8550]

Great tutorial.

[@BenjaminAnoh]

great video but can we have the code for this video to follow along?

[@sinanguler3907]

Great video again, thank you.

[@Mani-xx4fz]

Excelent tutorial 👏

[@pujiwahono6563]

Please share source code this project

[@iuriipaterega26]

thx. great video

[@nareshkaira6513]

HI, can u make an video using soap service,(xml format) how we can parse the data to table view.

[@kelvinfok]

Great video, thank you so much.

[@subysukumaran3803]

Is it possible to mock the core data?

[@ak9tgaming714]

Awesome tutorial! Is the source code available on github?

[@jeraldo4571]

Really great video. Thanks! I am just about to start writing unit tests for the API request in my app. Just a question, if I do stubbing on my tests, that means that whatever happens to the backend is none of my concern? Since in stubbing, I provide the expected results and I base my tests on it. So in a case that there is a production app, any change in the backend that causes a runtime / logic error in the client, will never be caught by the unit tests that are using stubbing?

[@nasir519]

I would definatly enrol for your Udemy/Skillshare course of XCUITest for intermediate or Advance concepts, Please let me know if you have prepared anything like that.

[@rafaeashraf605]

any possibility of releasing a quick video that shows how to build a networking layer that can easily send requests just by method calls? I'm having a bit of trouble structuring my own at the moment. Great video anyhoos!

[@CodePro]

I think one of my first tutorials a long time ago covered this with URLSession but I do plan on making an updated tutorial that will add in how to architect this as well.

[@danyalOFF]

you can something like routing with enum structure. there are plenty of tutorials how to structure this type of endpoint call. this approach is really easy with alamofire framework

[@rafaeashraf605]

I was thinking about this but wasn't so sure if it would work with multiple requests from different points in the app. I've created a singleton instead that has multiple methods that can either send a get/post request for now. I was either thinking of creating a wrapper function that passes the url and returns the object to that class. I dunno I'm kind of stuck on this at the moment and trying to stick to URLSession. Thanks though!

[@rajujsk]

Thanks for the Good video. I have a question, does writing Unit test with Mock data helps in increasing Code Coverage? I think the point of writing Unit test cases makes sure the actual code works as expected during the real time, but when it doesn't increase code coverage, how do we validate that our real code is working fine?

[@CodePro]

Mock data in and of itself will not increase code coverage. Supplying mock data to your APIs will allow you to test all possible paths because you can mock the responses. Your APIs and real code should only work on the data they are given (real / mock). The idea is you mock your data to look like the real API data. However your responses are simulated instead of talking to the live services. Assuming your mocked data closely mirrors the real data you expect then you can test all parts of your API regardless of the real data and real API responses. If you don't do this and choose to make real network calls that respond with real data in your unit tests, you'll know when your services go down when your unit tests start failing all of a sudden. This is bad because most of the time your unit tests are a final step in a CICD pipeline. Failing unit tests because your remote APIs are down in (stage/dev) environments should never block pull requests or releases where production services are working correctly. This is why mocking your responses is valuable.

[@Mani-xx4fz]

Superb! by the way ..have u got any available course about this advanced iOS topics?

[@CodePro]

Not yet, but more advanced full length content will be coming that covers these topic.

[@Mani-xx4fz]

Cool! Keep it up 👍

[@anderltz]

Great content. How do you test coreData?

[@CodePro]

Great question, one of the easiest ways to test core data is to use a in-memory persistent store type instead of SQLite. That allows you to test all your Core Data logic but without persisting it to disk in the unit tests. Although you can persist to disk as well if you prefer you just have to make sure you clean up any data saved between each test and change the save location of the database on the filesystem to point somewhere that won't clutter your app file directory space.

[@hemanthawijesinghe8636]

Great explanation ... Is there any sample code ?

[@CodePro]

Yes, I provide source code but that is a perk for my Patreon supporters.

[@mohammadjahidhussain2561]

Thanks for the Course, but i have doubt that since we are mocking the network call and we have our own Mock response too, If the server side team changes some data then will our Test fail? If yes How? Since we have our mock response based on our model, Our test will always pass even if there are changes from server side team. Kindly correct me if I am wrong.

[@CodePro]

That's a good question but generally the API will be written out and agreed to before the client side and services teams may have even started coding. Based on that API spec / contract it is reasonable enough for the client side team to operate under those assumptions unless the services team changes those contracts later on in development. A great way to encapsulate that contract is using protocols. Your models can conform to protocols that will govern what properties / data types you should expect a model to have based on what comes back from the service response. If the services team changes those responses without informing the client side team then your app may crash or may even be missing data in the model layer if the app doesn't crash. But the value in mocking the responses is you can test your parse logic against scenarios where: data may be missing, data may be the incorrect type, there may be extra keys in the response that you can simply ignore, and guarantee that under poor circumstances, your parsing logic will fail gracefully instead of outright crashing the app.

[@mohammadjahidhussain2561]

@@CodePro Thanks for the explanation.

[@adeadegoke4925]

@Code Pro I think you should do some user testing on your tutorials. This tutorial is far too advanced for a beginner.

[@CodePro]

Thanks for the suggestion yeah this one is a little more advanced. I try to switch it up from time to time but I’ll keep that in mind for future content.

[@mobiledevlife]

Really good explanations and tutorial, I'm an iOS developer too and I find this quite useful, especially since I try to do more unit tests lately. Regarding your implementation with ApiClientProtocol and the ApiClient class, I have a question: - What do you think about protocols with default implementation? I worked on a project where we had protocols for API calls just like you (LoginApiProtocol, UserInfoApiProtocol, etc) but instead of conforming classes to these protocols, we used default implementations directly in the protocols (with extensions). In this way, you can easily add these protocols to any other class (and use the API requests from there) but it's difficult to mock them. What's your call on this? Thanks!

[@CodePro]

This is a good question and it really depends on how default protocol implementation are used. Generally this is fine but you may run into issues if you start to subclass things in certain scenarios. Things that are heavily re-used, likely won't change, and are isolated are good candidates for default protocol extensions but treat it on a case by case basis. And yes, this can make things harder to test so if you want to be able to mock something you'll want to consider this as well.

[@mobiledevlife]

@@CodePro thanks a lot for your thoughts. I agree, we need to look at each specific context and decide then :).