Download to read offline
16 - 17h10 - Anthony Todisco_Amadeus.pptx
- 1. Agile testing forweb API with Postman Presented by Anthony Todisco © All rights reserved
- 2. Agenda • API andAgile • API testing • Rest-assured • Postman • Our journey with Postman • Key takeaway • Q&A © All rights reserved User Conference on Advanced Automated Testing
- 3. API and Agile •Growth in the number of API • Importance of time to market © All rights reserved User Conference on Advanced Automated Testing
- 4. API and Agile •Agile methodology to produce quick results • But UI testing is currently: • too slow • Not adapted to Agile © All rights reserved User Conference on Advanced Automated Testing
- 5. API and tests •Test automation is the key • Multiple possibilities for test automation © All rights reserved User Conference on Advanced Automated Testing Which one to choose?
- 6. Rest-assured test • Firstchoice for most people • Java Domain Specific Language (DSL) for test • Support response parsing (XML and JSON) • BDD Syntax: • Easy reading • Maintainable • Source code and tests in the same project © All rights reserved User Conference on Advanced Automated Testing
- 7. Rest-assured test • Noreport need another unit test framework • What if your code is not Java ? • If your QAs are not developers ? © All rights reserved User Conference on Advanced Automated Testing
- 8. Postman • A UItool for API testing • Good for: • Exploratory tests • Functional and automated tests • Easy to use • Support response parsing (XML and JSON) • Define the concept of collection for a group of requests © All rights reserved User Conference on Advanced Automated Testing
- 9. © All rightsreserved User Conference on Advanced Automated Testing
- 10. Postman • CLI (Newman)that integrates greatly with Jenkins • CLI, XML and HTML reports • Support SOAP call • Basic Javascript testing with boolean © All rights reserved User Conference on Advanced Automated Testing
- 11. Our journey withPostman: Split © All rights reserved User Conference on Advanced Automated Testing 488000 lines 1830 lines 500 lines 2100 lines Less than 4000 lines
- 12. Our journey withPostman: Combine © All rights reserved User Conference on Advanced Automated Testing
- 13. Our journey withPostman: BDD © All rights reserved User Conference on Advanced Automated Testing
- 14. Our journey withPostman: Replication • Saved re-usable functions into Postman environment • Use the collection structure at your advantage © All rights reserved User Conference on Advanced Automated Testing 510 lines on every request 5 lines on every collection
- 15. Our journey withPostman: Feedbacks © All rights reserved User Conference on Advanced Automated Testing 80 % Easiness Better communication Reduction of file size (after splitting) 30 % Between developers, QAs and PO with BDD Using BDD and re-used function Time reduction on develop/review per US
- 16. Key takeaway • Simpleyet powerful tool • Use small collections to share work • Integration of Newman with Jenkins • Avoid duplicate code by using environment • Use Collection structure to your advantage © All rights reserved User Conference on Advanced Automated Testing
- 17. Thank you Any questions? ©All rights reserved
Editor's Notes
- #4 Today, we see an explosion of the number of web APIs in the industry due to the popularity of the client-server paradigm in consumer and business products. More and more companies are making the shift-left towards DevOps continuous integration and continuous deployment development, because time to market is the key in today’s business That means development and our feedback need to be quicker than ever in order to determine if our applications are ready to ship or not.
- #5 The Agile methodology is a great help to quickly produce value, respond to customer demands and have feedback. However focusing only on UI automation can kill your test automation efforts. There is a host of reasons why. The main one being that UI tests are notoriously slow. That singular reason is why API testing is so important and why you should have it as part of your overall automation strategy.
- #7 Rest-assured is one of the top answer for this question and for most people first choice for automation. Rest-assured is a fluent Java library you can use to test HTTP-based REST services. It’s designed with testing in mind, and it integrates with any existing Java-based automation framework. It provides a BDD-like DSL that makes creating API testing in Java simple. It also has a bunch of baked-in functionalities, which means you don’t have to code things from scratch. If your team is made up mainly of Java coders, this will be the best choice
- #8 At first glance, Rest assured seems to be the perfect solution But, it does not have a integrate way to export result in HTML or XML, you will need another unit test framework for this Other point, if your project is not in Java, will you choose to use another development environment for test ? And last but not the least, if your QA team is not found of coding
- #9 You might want to consider Postman. Postman is a nice option for exploratory-type API testing but it’s also powerful enough that you can create more integrated solutions if you wish. It is a UI tool to test API by sending web request and getting back reply
- #11 Postman also has a command line integration named Newman that interacts very well with Jenkins This command line allows you to have a CLI, XML and HTML report. Moreover, you can also create your own export and customize the output template Postman also support SOAP call for your tests And finally tests are written with basic javascript Show example of test
- #12 Ok, so now, you’ve seen why we choose Postman. But even if everything seems good, we faced some “issues” by using it At first, we have a nice collection with some tests. Then, we started to add more and more tests in it and finally we get a really big file. Since we were multiple people working on it, it begun to be difficult to follow what was exactly changed on our source control tool and we faced some issue while merging So we decided to split our big collection into small ones. And like this we gain on checking time, on merge time and multiple QA can works on the same time
- #13 As a counterpart of the split, we cannot generate anymore our full report file. Indeed, to generate this, the Newman command take only one collection file as input. So, using the some infos provided by Postman and the fact that collection files are JSON files, we created an internal tool, that we named orchestrator, to combine them into one and retrieve our first big collection. After that we can run back our Newman command And Tada!!! Back again with our beautiful report
- #14 Reporting and sharing tasks problems solved But remember we are an Agile team and in an Agile team, the testing part involve everyone So why not using BDD in order to achieve this The basic testing way in Postman is not fit for this approach Postman is in fact a node application, so we can load by using a little javascript trick an external code Like this we can load a describe-it syntax that makes our test structure more readable With this, we can share with all the team and even externally this kind of test skeleton in order to validate our behavior It also loads methods that help you writing in a human readable language for the tests
- #15 Everything seems nice now But we’ve found another point that we wanted to fix: the code replication Indeed, some tests and even some part of the tests were repeated on multiple places and if there was even a small change, we needed to update every collection we created. Postman gives you a helping hand on this with two things: Save functions in Postman environment Use structured call to avoid duplication In Postman the basic workflow is the following, you send a request and receive a response on which one you can run your tests You can even define some actions on a pre-request script In order to avoid duplicating some code, you can use the structure. You have a Collection level pre-request script that will be call before every requests, then another one at folder level and then the current request pre-request script The same apply to test scripts