I recently started doing a project which involves some API testing. Since my knowledge of this domain was restricted and began to learn of lot of things as i started….. This is the first time i thought ill blog about it as i go along.
How to design and API testing framework ???
Coming from an automation addicted software testing background, when i started to study API testing one of the things that i found out (to my delight) was that when it comes to testing API’s, there is not much that you can do by sticking to the age old manual testing routine.
This bought me to the next question, what would be the architecture of an API Testing framework? The following notes are regarding the pre-requisites of your test framework irrespective of whether your API is written in C,JAVA etc etc…. As usual let me start with a picture:
The framework is more or less self-explanatory. The purpose of the config file is to hold all the configurable components and their values for a particular test run. As a follow through, your automated test cases should be represented in a ‘parse-able’ format in the config file. Always keep the script highly ‘configurable’.
In the case of API Testing, you would not want to test every API in every test run ( the number of API’s that are tested will dwindle as testing progressing.) Hence your config file should have sections which detail which all API’s are “activated” for the particular run. Based on this, the test cases should be picked up.
Since inserting the automation test case parameters into config file can be a tedious activity, it should be designed in such a way that the test case can be left static with a mechanism of ‘activating’ and ‘deactivating’ them.
More on designing and real experience in later posts…………………………….
![]( "test_framwork")
If you enjoyed this post, make sure you subscribe to my RSS feed!
Related posts
Been a looong time since i sat down to blog, (assumption being that you need to go out and learn something new to blog something new). After another burst of heavy testing, i gathered a few essentials of writing good perl scripts for automated testing. Here are a few observations. I hope to continue this serious……
1. Logging is everything - This is one obvious thing that most automation framework developers dont concentrate much on. As a QA person the application log file dump is the first place we go to track/analyze a defect. Similarly when an automation perl script is developed a standardized log record of the various tests and outcomes is very helpful. A good format for (found in most standardized logs would look something like this:)
<timestamp> <Tag>: <Descriptor>
The Tag should be a finite list of callouts like: Fail, Pass, Info, Checkpoint etc.
This is purely for the puropose of running overall searches when you log files become huge. For example, after every run of the script, the tester would be interested in Fails (obviously). This is where these tags
come handy. A simple search for “Fail” would tell me where all the test has failed.
2. Non-interactive automation scripts: These are cases where the user inputs (if any) are recorded into .conf (config files). This helps “silent runs” of the test scripts. Designing good config files are very important. Be sure to provide flexibility of ignoring comments and blank while parsing config files for parameters. See a sample perl code snippet below
s/#.*//; # ignore comments by erasing them
next if /^(\s)*$/; # skip blank line
chomp;
push @test_cases, $_; # push the data line onto the array
Another possibility would be to ignore comments at the end of a line also like:
[test_case_login]
username=mike #place where the username goes in
password=gogogo #place where the password goes in
From a readability perspective, provide users of your automation framework to have such comments in their config files, (make sure you handle these types of comments also). Checkback with me if you need a code snippet for that (Exercise for the reader 
If you enjoyed this post, make sure you subscribe to my RSS feed!
Related posts
