APIs are interfaces. It’s in their name. Interfaces in software allow to decouple the “what” from the “how”. The function from the implementation. API testing should reflect that, right?
For example, when a user calls a REST request like this, for getting the user’s details:
They don’t care what’s the implementation like. Or what kind of server they are using. Or what language they use. Or what database is behind it. If at all.
That’s a good thing. If I’m responsible for building the back-end, that means I can replace a database, or start the move from Java to Node.js. And the user wouldn’t know anything about it. That gives me flexibility. It gives me options.
I Love the Smell of Black-Box in the Morning
When we test, we’d rather have that black-box feeling. It makes us feel that we’re testing the system better (than it would be under white-box testing rules).
In fact, when I was a young team leader, I was told to never let the testers know how the software actually works. Let them have no prior knowledge that might affect their testing.
Is that “testing better”?
The purpose of testing is to learn, and then report, as much as possible about our system. The good, the bugs and the ugly. When we fulfil this purpose, we can make better decisions.
For this definition, “testing better” means gaining more and in-depth information.
So is black-box testing better than white-box testing? In our case, is checking the API behavior (without that “behind-the-scenes” dirt) better?
API Testing – The Battle of the Boxes
Here’s an example. Let’s say you have two architecture options of how the API is implemented and deployed.
Here’s the first: Everything – controller, logic, database – all in a single box.
Here’s the other one: Every component – controller, logic, database – each is deployed in its own container.
Same code, same frameworks, different set-up. Now, if you used the internet before, and I am counting reading this blog, you know that in the second option, there’s good possibility of connectivity and latency issues. The first one – not so much.
Does this knowledge of “how the system works” change your testing plans?
It should. In the second deployment option, I would budget some time to check how the system behaves, when the database vanishes. But with the first option – not so much. I would the spare time for testing other areas more deeply.
When I started testing, I was told to ignore what the developers did. With our systems today, it’s pure negligence to disregard any architectural, design or code information, when we’re testing.
We need more information, and we want to make better use of our time. Knowing what’s happening inside is essential for “testing better”.
And if you want to test better, why not check out my “API Automation Testing” workshop for developers? Or my “Postman API testing” workshop for testers? Take a look inside and make better decisions.
0 Comments