| || |
API tests of features already covered in UI tests
I would like your advice dealing with the situation I am facing. For the last year or so we have been testing functionality of our web application, both UI (buttons, fields, etc') and business logic, via UI tests, both automated and manual. The development/testing ratio was roughly 10 days of development Vs 1 testing day.
Recently, however, I have encountered a new situation: another division (let's call them division X) in our organization wants to use our APIs. In order to enable this, a new development team was founded, a team which takes the existing APIs, tweaks with them a little, and hands them over to division X for them to implement in their application. This creates a huge problem for me, as the APIs were never tested as standalone features, only as part of the application/UI. So currently, sometimes a developer only works on an (existing) API for 2-3 hours, resulting in 1-3 testing days for me!
I feel torn. If I test the modified APIs as new features, I feel like I'm double testing: they are mostly old features, stripped of their UI and maybe modified slightly. Why do I have to spend a full days testing an API of a feature we have been constantly using and testing for over a year now? On the other hand, if I don't test, or reduce the testing scope dramatically, I'm risking missing bugs which might have been induced due to the (minor) modifications the API went through or even problematic file deployment.
So...what am I to do? Test each modified API as a new feature (even though it is not) or take huge risks and assume that since the API is used (albeit differently) in the web application "everything should be OK"? Or maybe there's a third option I'm not aware of?
Re: API tests of features already covered in UI tests
I'm not sure what "test as a new feature" means for you, and how it is different than "test as an existing feature which is being modified, and which has a new set of users".
You haven't tested the APIs before. You may have used them, but clearly that's different than testing them.
So plan on testing the APIs as you would any other untested feature. One thing that may speed things up is that your prior indirect use of the APIs should make for less risk. You might be able to assume that you will encounter fewer bugs.
Another upside is that if the UI actually uses these modified APIs, you might be able to do less UI testing in the future.
And often automating the testing of APIs is far more straightforward, and less brittle, than testing through the UI. You might find that it's easier to construct a fairly comprehensive suite of automated tests to help speed up the testing and improve the quality of your system overall.
Testing the APIs themselves is still additional testing, and hopefully you have additional resources to accomplish this new task. If so, it could be a win-win for you and your company.