-
Notifications
You must be signed in to change notification settings - Fork 0
Writing a function library for Github Repository API testing
When writing tests in DTF you'll find that you may be copying and pasting the same group of tags from one test to another and that it would be useful if you could group those into a function and call that with the right arguments instead. DTF has a built in function creation/calling feature that you can easily use in this scenario. Lets take the same 3 APIs calls from the previous Github test and create 3 functions that can be used by anyone who wants to call those APIs without having to worry about the exact URL to hit or the exact tokens to pass along.
The first API would be the create a repository API:
<function name="create_repository">
<param name="user" type="required"/>
<param name="token" type="required"/>
<param name="name" type="required"/>
<param name="desc" type="required"/>
<param name="homepage" type="required"/>
<param name="public" type="required"/>
<urlencode source="${desc}" result="desc"/>
<urlencode source="${homepage}" result="homepage"/>
<property name="args"
value="name=${name}&description=${desc}&homepage=${homepage}&public=${public}"/>
<http_post uri="${github.baseuri}/xml/repos/create?${args}">
<entity>login=${user}&token=${token}</entity>
</http_post>
</function>
As you can see above you can use every single tag available within DTF to create your function and easily identify which of your arguments are required or optional, while specifying defaults in the case of an optional argument. Calling this function from another test is as simple as using the import tag to import all available functions from another file and then using the call tag to issue the actual function call.
I have created the rest of the API calls as functions as well and recreated our github_test1.xml using these functions and you can find the new test at github_test2.xml. The function library can be found at tests/examples/github/util/util.xml which contains the 3 functions that map to the 3 repository APIs mentioned earlier.
Although the new test isn't much shorter than the first one it has the advantage that any future changes to the API or if the API changes and we can make a small default additions to the util.xml and handle the API differences in the call without having to change the test then we can easily test the newer API and old API without having to change the tests themselves. Functions are useful in this scenario but writing up your own Tag implementation is going to allow you to do things within your Tag's code to handle future changes to the API in a more robust and cleaner manner.