In this API unit testing video, we will explore how we can write unit tests for our API code. We will discuss the scenarios that we will cover for this test case first and then we will explore a new concept called black-box testing and why it's important to have 1-2 black-box tests for API. Please feel free to ask questions on this topic as a comment or via email and do like and share the video and if you are new to the channel then please subscribe :)
Hey Chaitanya, Welcome to the channel. I am glad this video was helpful please feel free to ask questions and do share the channel with your iOS group :)
Ravi, may I know in which case we should mock the data? And API call is async call it takes time to get the response from the server like images, etc. so in this case what do you think, what should do? Should I still be directly calling to API or should I mock that API? I may be wrong in the term of 'Mock', please understand and respond.
Hi Ravi, your explains with example's it's simple :) Awesome, I strongly believe that, your videos are really help for all iOS developers. Thanks you for that. I would like to request can you, to make one video on "How to write test cases for API's those test cases should run offline and online". without making any additional changes
Hey Reddy, welcome to the channel. Can you put some light on what you mean by writing test cases that should run in offline mode? You won’t be able to hit an API in offline mode and I personally am not a big fan of mocking frameworks as they add negative results at times. For APIs and databases its always a good idea to make a real call and not mock them but let me know more on what thag offline term means I’ll see what i can do
@@CodeCat15 Hi Ravi, Really thankful to you for quick replay :) "How to write test cases for API's those test cases should run offline and online". What I mean is "How to mock web-services and data base CURD operation functions" and how to write Unit test cases for those method.
Ohh I see, are you inclined more towards an offline sync functionality? Like offline store some records and when net comes in push those records is that it?
Hi Ravi, Thank you for the video. I have one question when we are writing test cases for the function where we call API, dont we need to write "async throws" after functionName() .
Mocking is mainly used when the APIs are not ready, but once they are mocks should be deleted. There is no rule as such that mock and API unit test cases cannot exist in the same project, but mock will always say the half-truth. Mocks will always return you the data that you hardcoded and the side effect of that is you have to maintain a mock object for every use case you can think of and if your API returns you some new data dictionary you have to include that as well which I feel is a pain but some devs do that and it's fine I mean as long as your mock mirrors what your API is returning you should be good. I personally being a lazy person not in the favor of writing mocks because I have to maintain them also if I pass on the project to a new dev and if they forget to update the mock object then we have an ambiguity where your mock object does not mirror the real API object so that's my reason for including mocks only at design phase when my API is not ready but then once they are I delete all the mock code and replace the mock test cases with the code where I am calling the real API.
Nahi, ek aisa test case liko jo aise email id ko test kare jo server pe na ho. Agar api sahi kaam kar rahi hai to expected result aayega varna test fail ho jayega
Yes you can do that for global objects in the tests but i mostly skip it if my code does not require too much setup but usually its a good practice to use them.
Xcode 11 onwards setupwitherror is introduced so if we do any code in initial method we can catch the error as-well. i.e., fetching api response in beginning, when multiple test cases are going to use the response.
Hi bro...your videos are helping me a lot to lear more and this the best and useful video..And can you please tell me is there any change to get automatic send mail about Repot Test Coverage .If yes how can we do...
Indeed for that you need to configure a CI pipeline with jenkins or travis CI or azure whatever your company is using and you can set some restrictions like if your code coverage is not greater than or equal to 70% then don’t create the pull requests or just fail the current build and when the build fails you will surely get an email with the reason why it failed
Hi thanks for explaining this topic, the api testing that you have explained is dependent on internet network connection so i think we should not use this test cases in our app. Can you make a tutorial on stubbing with Mockingjay.
Calling a real API in a test case is a part of what we call as black box testing, where you should really hit a real api with good and bad request objects just to make sure that the API responds as expected. I am not a big fan of mocking because I think if the API changes its response structure then in that case we need to update the mock as well so there's a bit of maintenance overhead plus to add more to that point if the response structure does change and you have a black box test case and a mock test case then in that case the mock test case will pass because its dealing with the old response structure but the black box test case will fail indicating that there's some change in the API response structure so really having a mock can be a false positive at times so I avoid it.
Thanks a lot for this video. How to write tests for APIs where we are using models with JSONCodable. I mean how to validate that type of APIs which returns the list of movies for example and we parse it to a model. what parameters we can use to validate the response.
it's probably going to be similar as to what you see in the video, the only thing you would need to do is assert on the collection to see if its empty or not and on certain values in a loop, I can show that in some upcoming videos or if it's urgent then send me an email I can send you a sample code for the same. Hope it helps
@@CodeCat15 Thanks for reply, my question was like I have a method A which completion is notify by delegates method than how can I write test case for method A.
earlier I used daylight mode, but I got emails and messages on my Instagram to switch to dark mode and not daylight so looking at the majority i switched to dark mode, I am sorry if it has caused any inconvenience to you.
How to write API test cases where request keep changing. I mean to delete record need to give record ID in request so how to write test case for such scenario?
From the requirement you mentioned I would just add an int property in my delete request model and that should be it. struct DeleteEmployeeRequest { let employeeId: Int } Records should always be deleted based on id and not on anything else. Let me know if that answers your questions and if not then feel free to ask more
I am sorry if that has caused any inconvenience I try to keep the language in Hindi but sometimes unknowingly I keep on saying few statements in English and then switch to Hindi again. I am working on it and once again sorry if it has caused any inconvenience to you
Few observations. APIs should never be tested from client (ios/android) How can you use hardcoded messages in asserts ? What if server changes the text ? API responses should be mocked via protocol confirming mock models which should be passed as dependency to service Adapt clean code and prefer writing tests along with code ‘Wait’ with timeout should never be used as it causes tests failure due to timing issues.
Your test suite must have BARE MINIMUM integration tests, that make calls to an actual endpoint, it's called black box testing. If one simply uses mocks, then mocks end up returning true/false objects based on how you configure them. This could be fine in some cases but mocks fail to provide the following details 1. Changes in the API response structure 2. If the API is live or the endpoint has changed 3. End to End functional testing 4. Risk of integration testing 5. Performance bottleneck from the API 6. Failing to validate the API behavior when passing different request parameters Understand that you can mock all the above, but the area of change is the API, and when the API changes you will be forced to make changes in your mock tests too and this becomes a maintenance overhead with mocking. This could also become a disadvantage when the API response changes and the dev forgot to update the mock, so now the test suite passes giving false test results and high code coverage, is that good practice? No In the end, it's up to the development team as to how they want to write tests, is it just for code coverage or to do actual functional testing? Everything cannot be tested with API integration testing, and hence I used the word BARE MINIMUM.
@@CodeCat15 Why should a test case perform live API testing? what if CI/CD machines have restricted access or some APIs are blocked ? What if aPI takes time, your timing 'wait' will end up in failing tests. coming to your point when you said 'what if the structure changes' for that use strict codables with non optional vars and put asserts and logs if any of the expexted values changes. The API testing is server side job not client job. How can an app tests be responsible for failing API responses? Servers can go down any time and its bad Idea to rely on servers for the data source. For any tests, the source of data should be generated as mocks for different possible conditions. When you said maintenance overhead, I am only suggesting to mock the data not the actual classes. Further more, any 'layer' which is used by any other system should be passed as dependency. In your case you should have passed the actual service as dependency which intern provides the data needed to test.
@@dhaneshshastri1 I'll create a separate video explaining mocks and their drawbacks in detail with technical reasons & examples as to why I am suggesting writing bare minimum integration tests. You don't need to use strict codable types because if the API response changes the mocks will pass but the integration test will fail because the decoder will detect the change and will throw a runtime exception, try it out for yourself and see the difference between mocks vs integration tests and hence I recommend have BARE MINIMUM integration tests. Non-optional vars are not a good idea because not every property in the response will have a value it can be nil too and non-optional means you are expecting a value from the API which again will result in a runtime exception unless you swap them with default in the decoder init function but again that's not advisable. Example: If you are working on a calculation then giving the default value of 0 can mean different thing in different context so I just mark In testing integration and unit testing go hand in hand but unfortunately, developers tend to be fixated on mocks which is kind of sad because most of the bugs are discovered in integration testing and not in mocking and unfortunately devs fail to see this fact I am not suggesting testing every API just test the ones that you think are important if you truly care about testing Obviously, it's the responsibility of the API team to write tests for the APIs which they usually do all the time, but on the client side, the developer will be INTEGRATING those APIs in their app and hence as part of INTEGRATION TESTING they should write BARE MINIMUM INTEGRATION TESTS for the apps. Check the video at 2:32 here too I am suggestion write 1-2 integration tests By maintenance, I too meant to mock the data and not the whole class, and since this was a demo I didn't use a protocol but you must use a protocol in your app and pass it as a dependency when you generate a stub for your tests You would still have maintenance overheads with stubs and it's dummy data irrespective of what you do since one MUST keep track of all those dummy responses and ensure they match what the API currently returns, failing to do so will result in stale unit tests or garbage tests. I would like to explain that in the video soon with an example of how these stale unit tests are born and the damage they do, please feel free to ask more questions I will try to answer them in my video. Thanks.
@@CodeCat15 I am not saying 'Mock everything' its just for APIs you dont have to reach servers in tests. tests should be done in isolation to test your code. The unit testing is for making the code work as expected even if any dev in future does a single line of change around the logic area, the tests will make sure everything works. This is what is the purpose of unit tests. I repeat, I am against mocks, and I support integration tests with complete BDD rather than the plain TDD. TDD has to be there but it does not always make sense for everyone ex. stake holders but BDD does. Here is where the integration tests comes in. The server should never be hit in case if tests. Coming to your codable point, if a value has to be optional it has to be kept optional. APIs should be designed considering actual business need in mid and server and client should be strict on that. If a key in response has to be there then its bad practice to keep it optional.
@@dhaneshshastri1 I guess we both are saying the same thing just the wordings are off, i too don’t favor mocks but there’s value in them and with integration testing my opinion is to write bare minimum tests for MVP. For other things I’ll cover that in the video.
In this API unit testing video, we will explore how we can write unit tests for our API code. We will discuss the scenarios that we will cover for this test case first and then we will explore a new concept called black-box testing and why it's important to have 1-2 black-box tests for API. Please feel free to ask questions on this topic as a comment or via email and do like and share the video and if you are new to the channel then please subscribe :)
Hi Ravi your videos are really help to understand the concept thanks for all these video man may god bless you
First comment. Love your work buddy. 👍
Thank you Sayeed, I am glad this video was helpful. Please feel free to ask questions on this topic and do share it with your iOS group
Simply awesome. One of the great videos I have ever seen about testing. Keep posting videos like this Ravi.
Glad this was helpful Raja 👍 do share the same with your iOS group and feel free to ask questions on this
Ravi you Explain everything so well..!
Really thankful to you.
Hey Chaitanya, Welcome to the channel. I am glad this video was helpful please feel free to ask questions and do share the channel with your iOS group :)
Ravi, may I know in which case we should mock the data? And API call is async call it takes time to get the response from the server like images, etc. so in this case what do you think, what should do? Should I still be directly calling to API or should I mock that API? I may be wrong in the term of 'Mock', please understand and respond.
Hey Ravi can you please add a video on test doubles like stubs, mocks, spy, fakes etc? These are also a great part of unit testing.
Hi Ravi, your explains with example's it's simple :) Awesome, I strongly believe that, your videos are really help for all iOS developers. Thanks you for that.
I would like to request can you, to make one video on "How to write test cases for API's those test cases should run offline and online". without making any additional changes
Hey Reddy, welcome to the channel. Can you put some light on what you mean by writing test cases that should run in offline mode? You won’t be able to hit an API in offline mode and I personally am not a big fan of mocking frameworks as they add negative results at times. For APIs and databases its always a good idea to make a real call and not mock them but let me know more on what thag offline term means I’ll see what i can do
@@CodeCat15 Hi Ravi, Really thankful to you for quick replay :)
"How to write test cases for API's those test cases should run offline and online". What I mean is "How to mock web-services and data base CURD operation functions" and how to write Unit test cases for those method.
Ohh I see, are you inclined more towards an offline sync functionality? Like offline store some records and when net comes in push those records is that it?
Happy new year sir thanks for video i hope your channel grow exponentially this year.
Thank you buddy, and a happy new year to you too :)
Thank you So You are Really Great Sir
Thank you so much Ravi bhai 😊
anytime buddy :), please feel free to ask questions on this and do share it with your iOS group too
Thanks Ravi... Your are awesome learn lot for your video ...
Glad to hear that Yogesh
Awesome work man thank you so much for your time
Thanks Abid, I am glad this video was helpful to you
Hi Ravi,
Thank you for the video. I have one question when we are writing test cases for the function where we call API, dont we need to write "async throws" after functionName() .
Thank you for creating such amazing content ❤👍
Great videos, Please make videos on UI Testing too. 🙏
Hi, Can make the video of Unit test on singleton class.
@Code Cat Thanks for above videos they help a lot
Can you please create video on UIUnit testing
Where we use cocoapod and package manager in ios . Please create one video
Please make a video on CI/CD in iOS
Can you give some demo on api unit testing with moc/dummy response?
Can we MOCK the network data?
which is a better approach?
Mocking is mainly used when the APIs are not ready, but once they are mocks should be deleted. There is no rule as such that mock and API unit test cases cannot exist in the same project, but mock will always say the half-truth.
Mocks will always return you the data that you hardcoded and the side effect of that is you have to maintain a mock object for every use case you can think of and if your API returns you some new data dictionary you have to include that as well which I feel is a pain but some devs do that and it's fine I mean as long as your mock mirrors what your API is returning you should be good.
I personally being a lazy person not in the favor of writing mocks because I have to maintain them also if I pass on the project to a new dev and if they forget to update the mock object then we have an ambiguity where your mock object does not mirror the real API object so that's my reason for including mocks only at design phase when my API is not ready but then once they are I delete all the mock code and replace the mock test cases with the code where I am calling the real API.
Tutorial me Kaunasa background picture use kiya hai bhai
Jo mail id apne pass ki hai suppose vo server pe ho hi na jo kya case fail ho jayega
So humko test case postman pe api chal kr likhne chaiye
Nahi, ek aisa test case liko jo aise email id ko test kare jo server pe na ho. Agar api sahi kaam kar rahi hai to expected result aayega varna test fail ho jayega
Hi Ravi , very good tutorial. But have one doubt why don't you use setUP and tearDown method for initialising object and free up that obj?
Yes you can do that for global objects in the tests but i mostly skip it if my code does not require too much setup but usually its a good practice to use them.
@@CodeCat15 yeah thanks a lot for reply
Xcode 11 onwards setupwitherror is introduced so if we do any code in initial method we can catch the error as-well. i.e., fetching api response in beginning, when multiple test cases are going to use the response.
Hi bro...your videos are helping me a lot to lear more and this the best and useful video..And can you please tell me is there any change to get automatic send mail about Repot Test Coverage .If yes how can we do...
Indeed for that you need to configure a CI pipeline with jenkins or travis CI or azure whatever your company is using and you can set some restrictions like if your code coverage is not greater than or equal to 70% then don’t create the pull requests or just fail the current build and when the build fails you will surely get an email with the reason why it failed
Hi thanks for explaining this topic, the api testing that you have explained is dependent on internet network connection so i think we should not use this test cases in our app. Can you make a tutorial on stubbing with Mockingjay.
Calling a real API in a test case is a part of what we call as black box testing, where you should really hit a real api with good and bad request objects just to make sure that the API responds as expected.
I am not a big fan of mocking because I think if the API changes its response structure then in that case we need to update the mock as well so there's a bit of maintenance overhead
plus to add more to that point if the response structure does change and you have a black box test case and a mock test case then in that case the mock test case will pass because its dealing with the old response structure but the black box test case will fail indicating that there's some change in the API response structure so really having a mock can be a false positive at times so I avoid it.
@@CodeCat15 Thanks for the information
Thanks a lot for this video.
How to write tests for APIs where we are using models with JSONCodable. I mean how to validate that type of APIs which returns the list of movies for example and we parse it to a model. what parameters we can use to validate the response.
it's probably going to be similar as to what you see in the video, the only thing you would need to do is assert on the collection to see if its empty or not and on certain values in a loop, I can show that in some upcoming videos or if it's urgent then send me an email I can send you a sample code for the same. Hope it helps
Hi ravi can you please help me with How to right test case for delegate observer methods? Like methods which completion is notify by delegate.
Can you please elaborate more on that for me, the completion handler here is a delegate can you put some light on delegate observer methods for me
@@CodeCat15 Thanks for reply, my question was like I have a method A which completion is notify by delegates method than how can I write test case for method A.
Please upload video for ssl pinning.
Love your work, but I wish that it was completely in English which is my language. I find that combing Hindi and English makes it hard to follow.
I am sorry for the inconvenience i will start working on the subtitles very soon for this video.
bro, pls use day light mode screen , can visible clearly..... night mode is not looking properly..
earlier I used daylight mode, but I got emails and messages on my Instagram to switch to dark mode and not daylight so looking at the majority i switched to dark mode, I am sorry if it has caused any inconvenience to you.
Apne ui test case ka video nhi bnaya ?
Nahi vo nahi banaya maine abhi tak 😞
Waiting for ui testing video
Timeout 5 kyu set kiya I mean api response depends upon internet
Utne seconds mai agar response nahi aaya to yaha hum api devs ko bol sakte hai ki api is not performing well.
How to write API test cases where request keep changing. I mean to delete record need to give record ID in request so how to write test case for such scenario?
From the requirement you mentioned I would just add an int property in my delete request model and that should be it.
struct DeleteEmployeeRequest {
let employeeId: Int
}
Records should always be deleted based on id and not on anything else. Let me know if that answers your questions and if not then feel free to ask more
Why do you constantly keep switching languages?
I am sorry if that has caused any inconvenience I try to keep the language in Hindi but sometimes unknowingly I keep on saying few statements in English and then switch to Hindi again. I am working on it and once again sorry if it has caused any inconvenience to you
Few observations.
APIs should never be tested from client (ios/android)
How can you use hardcoded messages in asserts ? What if server changes the text ?
API responses should be mocked via protocol confirming mock models which should be passed as dependency to service
Adapt clean code and prefer writing tests along with code
‘Wait’ with timeout should never be used as it causes tests failure due to timing issues.
Your test suite must have BARE MINIMUM integration tests, that make calls to an actual endpoint, it's called black box testing.
If one simply uses mocks, then mocks end up returning true/false objects based on how you configure them.
This could be fine in some cases but mocks fail to provide the following details
1. Changes in the API response structure
2. If the API is live or the endpoint has changed
3. End to End functional testing
4. Risk of integration testing
5. Performance bottleneck from the API
6. Failing to validate the API behavior when passing different request parameters
Understand that you can mock all the above, but the area of change is the API, and when the API changes you will be forced to make changes in your mock tests too and this becomes a maintenance overhead with mocking.
This could also become a disadvantage when the API response changes and the dev forgot to update the mock, so now the test suite passes giving false test results and high code coverage, is that good practice? No
In the end, it's up to the development team as to how they want to write tests, is it just for code coverage or to do actual functional testing?
Everything cannot be tested with API integration testing, and hence I used the word BARE MINIMUM.
@@CodeCat15 Why should a test case perform live API testing? what if CI/CD machines have restricted access or some APIs are blocked ? What if aPI takes time, your timing 'wait' will end up in failing tests.
coming to your point when you said 'what if the structure changes' for that use strict codables with non optional vars and put asserts and logs if any of the expexted values changes.
The API testing is server side job not client job. How can an app tests be responsible for failing API responses?
Servers can go down any time and its bad Idea to rely on servers for the data source.
For any tests, the source of data should be generated as mocks for different possible conditions.
When you said maintenance overhead, I am only suggesting to mock the data not the actual classes.
Further more, any 'layer' which is used by any other system should be passed as dependency. In your case you should have passed the actual service as dependency which intern provides the data needed to test.
@@dhaneshshastri1
I'll create a separate video explaining mocks and their drawbacks in detail with technical reasons & examples as to why I am suggesting writing bare minimum integration tests.
You don't need to use strict codable types because if the API response changes the mocks will pass but the integration test will fail because the decoder will detect the change and will throw a runtime exception, try it out for yourself and see the difference between mocks vs integration tests and hence I recommend have BARE MINIMUM integration tests.
Non-optional vars are not a good idea because not every property in the response will have a value it can be nil too and non-optional means you are expecting a value from the API which again will result in a runtime exception unless you swap them with default in the decoder init function but again that's not advisable.
Example: If you are working on a calculation then giving the default value of 0 can mean different thing in different context so I just mark
In testing integration and unit testing go hand in hand but unfortunately, developers tend to be fixated on mocks which is kind of sad because most of the bugs are discovered in integration testing and not in mocking and unfortunately devs fail to see this fact
I am not suggesting testing every API just test the ones that you think are important if you truly care about testing
Obviously, it's the responsibility of the API team to write tests for the APIs which they usually do all the time, but on the client side, the developer will be INTEGRATING those APIs in their app and hence as part of INTEGRATION TESTING they should write BARE MINIMUM INTEGRATION TESTS for the apps. Check the video at 2:32 here too I am suggestion write 1-2 integration tests
By maintenance, I too meant to mock the data and not the whole class, and since this was a demo I didn't use a protocol but you must use a protocol in your app and pass it as a dependency when you generate a stub for your tests
You would still have maintenance overheads with stubs and it's dummy data irrespective of what you do since one MUST keep track of all those dummy responses and ensure they match what the API currently returns, failing to do so will result in stale unit tests or garbage tests.
I would like to explain that in the video soon with an example of how these stale unit tests are born and the damage they do, please feel free to ask more questions I will try to answer them in my video. Thanks.
@@CodeCat15 I am not saying 'Mock everything' its just for APIs you dont have to reach servers in tests. tests should be done in isolation to test your code. The unit testing is for making the code work as expected even if any dev in future does a single line of change around the logic area, the tests will make sure everything works. This is what is the purpose of unit tests.
I repeat, I am against mocks, and I support integration tests with complete BDD rather than the plain TDD. TDD has to be there but it does not always make sense for everyone ex. stake holders but BDD does. Here is where the integration tests comes in.
The server should never be hit in case if tests.
Coming to your codable point, if a value has to be optional it has to be kept optional. APIs should be designed considering actual business need in mid and server and client should be strict on that. If a key in response has to be there then its bad practice to keep it optional.
@@dhaneshshastri1 I guess we both are saying the same thing just the wordings are off, i too don’t favor mocks but there’s value in them and with integration testing my opinion is to write bare minimum tests for MVP. For other things I’ll cover that in the video.
Hey Ravi can you please add a video on test doubles like stubs, mocks, spy, fakes etc? These are also a great part of unit testing.