API testing: Difference between revisions

Revision as of 19:07, 28 May 2015

Revision as of 01:55, 29 May 2015

Line 8:

API testing is used to determine whether APIs return the correct response (in the expected format) for a broad range of feasible requests, react properly to [[edge cases]] such as failures and unexpected/extreme inputs, deliver responses in an [[Service-level agreement|acceptable amount of time]], and respond securely to potential [[Cyberwarfare|security attacks]]. <ref name="reichart1"/><ref name="layers"/> [[Service virtualization]] is used in conjunction with API testing to isolate the services under test as well as expand test environment access by simulating APIs/services that are not accessible for testing. <ref name="accelerate">[http://www.gartner.com/document/2642716 Accelerate Development with Automated Testing], by Nathan Wilson, [[Gartner]] December 30, 2013</ref>

API testing commonly includes testing [[Representational state transfer|REST]] APIs or [[SOAP]] [[web services]] with [[JSON]] or [[XML]] [[Payload (computing)|message payloads]] being sent over [[HTTP]], [[HTTPS]], [[Java Message Service|JMS]], and [[IBM WebSphere MQ|MQ]]. <ref name="stickyminds"/><ref name="guidance">[http://www.gartner.com/document/2827918 A Guidance Framework for Designing a Great Web API], by Eric Knipp and Gary Olliffe , [[Gartner]] August 20, 2014</ref>. It can also include message formats such as [[Society for Worldwide Interbank Financial Telecommunication|SWIFT]], [[Financial_Information_eXchange|FIX]], [[Electronic data interchange|EDI]] and similar fixed-length formats, [[Comma-separated values|CSV]], [[ISO 8583]] and [[Protocol Buffers]] being sent over

[[Communications_protocol|transports/protocols]] such as [[TCP/IP]], [[ISO 8583]], [[MQTT]], [[Financial_Information_eXchange|FIX]], [[Java remote method invocation|RMI]], [[SMTP]], [[TIBCO_Rendezvous|TIBCO Rendezvous]], and [[Financial_Information_eXchange|FIX]]. <ref>[http://www.drdobbs.com/tools/the-fight-against-brittle-scripts-and-so/231901658 The Fight Against Brittle Scripts and Software Defects], by Adrian Bridgwater, [[Dr. Dobb's Journal]] October 26, 2011</ref> <ref>[http://www.drdobbs.com/testing/how-do-we-learn-composite-app-testing-sp/232600874 How Do We Learn Composite App Testing-Speak?], by Adrian Bridgwater, [[Dr. Dobb's Journal]] February 14, 2012</ref>

==API testing, GUI testing, and test automation==

API Testing is recognized as being more suitable for [[test automation]] (especially the automation used with [[Agile software development]] and [[DevOps]]) than GUI testing. <ref name="layers"/><ref name="forrblog"/>Reasons cited include:

* <B>'''System complexity:</B>''' GUI tests can't sufficiently verify functional paths and back-end APIs/services associated with multitier architectures. APIs are considered the most stable interface to the system under test.

* <B>'''Short release cycles with fast feedback loops:</B>''' Agile and DevOps teams working with short iterations and fast feedback loops find that GUI tests require considerable rework to keep pace with frequent change. Tests are the API layer are less brittle and easier to maintain.

For these reasons, it is recommended that teams increase their level of API testing while decreasing their reliance on GUI testing. API testing is recommended for the vast majority of test automation efforts and as much edge testing as possible. GUI testing is then reserved for validating typical use case scenarios at the system level, mobile testing, and usability testing.<ref name="layers"/> <ref name="forrblog"/> <ref name="cohn">{{cite book | last = Cohn| first = Mike| title = Succeeding with Agile: Software Development Using Scrum | year = 2009 | publisher = Addison-Wesley Professional | ___location =| page =312| isbn = 978-0321579362}}</ref>