There are many 3rd party libraries out there and we developers are really happy about them. They give us opportunity to focus on our business code. Everything sounds perfect in theory, but in practice we may have some problems.
Because we don’t know:
- How exactly the library works?
- Does it meet all our requirements?
- Maybe documentation is poor or complicated and we may need to check it out by trying?
And there is even more…
Let’s say we decided to give it a try and use the library in our production and have some first hand experience. There are several ways to do that and one of them is:
- Create a branch
- Add the dependencies, implement it in our production code and start debugging/manual testing.
- If everything is OK, merge it to the master branch.
- If something is wrong or if it doesn’t meet our requirements, just delete the branch.
This approach has a few issues:
- First of all, we want to test the library, but we mix it with our production code. The result may have some problems and we don’t know whether the problem is the library or our production code.
- We need to run the application and we may need to do a lot of steps to go to this particular code and test it. For example:
Splash screen -> login -> few more clicks -> our test code
- Even if everything works fine, a new version of the library might be uploaded and we want to use it. New changes might have conflicts with the previous one and we may need to spend a lot of time to find out the problem.
Then how do we make sure the library is stable with all versions and meets our requirements?
Test it before integration
A real example: We want to use google places autocomplete API.
Using the Google Places API for Android, you can build location-aware apps that respond contextually to the local…
According to the documentation there are a couple of steps to get started.
- Add dependencies
- Add API key
- Connect to the Places API
We add the dependencies and started writing our test case. We want to make sure that our setup is correct and it connects to the Google API successfully.
Our first test will be to assert the connection status.
We run the tests.
The tests failed.
We have the following error which tells us to add the API Key.
We add the missing API key and run it again.
The tests failed again.
GoogleApiClient connects to the server asynchronously. Thus we change the test structure a little bit and wait for the response before running the tests.
We basically asserted our setup works.
Now time to test the autocomplete API. Basically, we add another test to assert that calling this API will return successful response.
We run it again
Great! All tests passed.
Now we can dive deep and do more tests to check if the API is feasible for our needs
- We assert that the 3rd party library meets our requirements
- We assert that the library works
- We have a test case that covers future version changes of the library
- We have a test case which will save us a lot of time when there is a bug
Write tests to save yourself from a lot of troubles.