Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Thoughts on Testing an API

Over the past few weeks I have worked on a few products for my client that will be used as API's.  These API's will be used by either their own (external) clients or other internal departments.  Working on these projects made me think about testing in a little different light compared to normal  testing.  I thought I would share some of my thoughts and experiences that I have learned while developing and testing API style applications.

First thing to keep in mind is that testing an API is not a whole lot different then testing a product (non-API), but you do need to take a few extra steps to ensure that your code is well tested and can be easily consumed.

Find the 'Main Artery' in your code.
This may seem pretty straight forward, but finding this Main Artery is critical on your journey to testing your API.  Unlink many 'standard' applications which have many entry points and exit points, API's tend to have a very few entry/exit points.  This means that many of the features of the API may flow down the same artery, which provided you a huge area of risk.

Finding this pathway is also critical due to the fact that the majority of your Use Cases are likely to travel down at least part of this path and if there is any type of issues with either your code or your logic, they will crop up all over the place.

Here is a little example
Imagine you have a 2 story house, and you want to go from the garage to the second floor.  When you enter the house via the garage door there are likely a few different ways to move around the first floor until you get to the stair well.  However, once you reach the stairs, there is only one way to get to the second floor.  The stair well in this example is our main artery.  If anything goes wrong with the stairs we cannot go from the first floor to the second.  Hence the need to find and test this code as heavily as possible.

Create as many 'Scenario' style Integration Tests as you can.
The best way to test your API is to not only create a solid set of Unit Tests that allow you to test your individual modules, but you also need to have a very exhaustive set of Integration Tests that allow you to run end to end slices through your API. 

You want to make sure that your API functions from the outside-in as desired.  The worst thing you can do is hand over your API and have someone else find an simple issue.  This type of testing will also allow you to test the performance of your API, if performance is something that you may be concerned with.

When creating your Scenario tests you will not only want to test known good data and known bad data, but also test with various random data.  Your goal should be to try to make your application fail, and in a bad way.  Creating tests for 'known' conditions is fine, but they will not ensure success.  Try to find edge cases and test as many of those as well.
 

Create a 'Test Application' that consumes your API as your expected consumers would.
Because your API is going to be consumed via 3rd party you should create some sort of stand alone test application for verify your API.  I would suggest you create a new .Net solution and add 1 project to the solution, with this project being nothing more then a test project  *** I AM NOT SAYING TO CREATE A UI APPLICATION ***.  By creating the stand alone solution you will learn how much effort or pain will be involved in consuming your API.  There are a few things in particular that you should look our for when consuming your API

  • Are they any configuration files that I need to deploy?
  • Are my entry points for the API clearly defined?
  • Do I need the consumer to reference any other assemblies besides my own?

You may find that your configuration setup is flawed, or you may find that you made too many assumptions about consumption during your initial development.  I know that when I did this I was enlightened to how my API was going to be used, and allowed me to better understand how to develop future features.

Finally, by consuming your own API you have a better understanding of how it works and this will allow you to create some sort of documentation on consumption of your API that can be attached to your code.  This can be huge asset to the API and can lessen the learning curve for your consumers.

 

The above thoughts/comments are purely created out of my own experiences, actual results may vary.

Till next time,


Posted 04-14-2008 7:32 AM by Derik Whittaker
Filed under: , , ,

[Advertisement]

Comments

Reflective Perspective - Chris Alcock » The Morning Brew #74 wrote Reflective Perspective - Chris Alcock » The Morning Brew #74
on 04-16-2008 2:55 AM

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #74

Test User wrote re: Thoughts on Testing an API
on 04-14-2009 5:39 PM

Hey Thanks for the excellent article !

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)