SmartBear Talks | Go Beyond – From UI Testing to ...
SmartBear Talks | Go Beyond – From UI Testing to API Testing - Bas Dijkstra
API testing is as important as UI testing. However, many UI testers don't realize the benefits of using API tests. At the same time, test automation at the API level is easier to create and maintain compared with automation at the UI level. Watch an exclusive interview with Bas Dijkstra, an independent test automation trainer and consultant, to learn about the pros and cons of using API testing together with UI testing:
Bas is an independent test automation trainer and consultant who takes pride in helping teams and organizations improve their testing efforts through smart application of tools. He consults with clients to help them take their first or their next step in test automation, or to help them get unstuck when they feel that their current test automation doesn’t provide the value it could.
Bas is an experienced trainer on various subjects related to testing and automation, delivering workshops and courses in house with clients and at conferences both in the Netherlands and abroad on a regular basis.
Any comments/questions/thoughts? We will be happy to discuss them - just leave a comment below.
Before we dive into API testing and UI testing, could you please share your background with the SmartBear Community members?
Sure, my name is Bas Dijkstra. I am a test automation trainer and consultant from the Netherlands. I've been in the test automation space for close to 15 years now. First as a salaried employee for eight years. For the last five-six years now I've been a freelancer. For the first ten years I did mostly consulting with various larger organizations through different sectors in the Netherlands. And, the last couple of years I’ve been focusing on test automation training courses or various topics related to test automation.
So API testing and UI testing are two the most important parts of testing nowadays. More and more people start using both of these testing types together. What do you think about this approach? Is it worth it?
Oh, yeah, definitely. Because there's no one right way of doing testing to me. There are situations in which one approach just works better than the other one, and they can definitely enhance each other, as well. To me, it is more important to be able to decide when which approach will work better than the other.
What should go first? API testing or UI testing? Or, is it impossible to separate them?
It all depends on what it is exactly that you're going to be testing. If you are going to test some back-end business logic that's exposed through an API to the front end, then it doesn't make sense to include that front end in the actual test because it'll only make your tests more cumbersome to maintain and slower to execute because the actual business logic that you're testing is exposed through the API. So, why not use the API to test that? But if you are simulating an end-user experience and you want to make sure that an end user can perform a sequence of actions through an interface and by interacting with the user interface before some actions on the back end, then you'll need to include the user interface in your testing because that’s an important part of the behavior of the application that you are testing at the moment.
One of the main challenges for me is - API testing can test a service, but, after that, this service will be integrated into the application. In API testing, you can test, and you can make sure that your service will process all possible requests and send corresponding responses, but once you integrated this service into the application, how can you make sure that this service will work fine inside the application?
A very good question. Depends on what it is that you want to test. If you want to make sure that the API can process all the different kinds of inputs that an end user can send to the API via the user interface, then you don't necessarily need the user interface because you can simulate the input that's coming through the user interface. But if you want to make sure that the responses that are coming back from the API are sent back from the API provider to the user interface layer, then you might want to build a test that combines them. If you really want to make sure that the response from an API is processed correctly in the front-end, then you might want to build an integration test that combines both layers. Or, maybe (and that depends a little on the architecture of the application that you're testing), mock the API away altogether and just simulate its behavior. Given that I expect the API to behave like this. This is a typical response that I expect from the API, just put it in as a mock in your front-end test because that makes your front-end testing a lot easier.
What I see a lot of teams and organizations doing nowadays, just by default combining everything and seeing how everything works together. You should definitely do that to some extent because it's important to make sure that all the layers and all the moving parts are working together nicely, but I see a whole lot of teams and organizations overdoing that because for a lot of the test cases and a lot of the situations that they're trying to verify, there are a lot more efficient ways of doing that.
You should typically just have a really small part of your automated tests combine those two layers, and if you're kind of verifying whether the UI can process typical responses for an API, you don't necessarily need the API itself do that. And, if you want to make sure that the API can process the inputs that are passed on through the user interface, you don't necessarily need the user interface. So you can do a whole lot more with separate layers than you think that makes your testing much more efficient.
Thanks a lot that was very useful and interesting. Is there anything that you would like to add that our API and UI world should be aware of?
Don’t be scared of API's. I see many testers that are making their first steps in the test automation world approach the application that they're testing just like they do when they were testing it. By default, a lot of people are still interacting with the application test just like an end user would, often through a user interface. And, that's good. That's a good starting point, but just be aware that for a lot of automated tests there are more efficient ways than that. Talk with your fellow testers, talk with developers, talk with architects and get a good overview of what your application architecture actually looks like, what layers there are. What layer you definitely need, what layer you don't necessarily need to verify the business logic or the behavior that you want to test. And then, try and find a way to build the most efficient test automation for that by using mocks or service virtualization or by leveraging API testing if you don't necessarily need the user interface. And, don't be scared to explore and learn new things about your application.
Also, just because you're testing something in the user interface doesn't mean you need all the layers that are below that. So there's a whole lot more that you can do just on the user interface level.
Great! Thanks a lot for the information. That was very interesting to learn more about API and how it can work with UI testing. Community, if you have any questions, just post your comments, and we will be happy to continue our conversation online in the Community. Bas, thanks for your time, thanks for the interview.
Thank you so much for having me Tanya, have a great day.