You definitely want to try to share your work with others. This applies to response maps, but also to many other things in iTest – such as session profiles, testbeds, reusable procedure libraries (stored in iTest test case files), form maps, etc.
The recommended way of sharing these kinds of files is via version control. iTest supports a variety of standard version control servers such as Subversion, CVS, etc. (iTest is built on top of Eclipse and can therefore take advantage of any version control system supported by Eclipse itself.)
In order to share your work, you need to make sure those files are in an appropriate iTest project, and you can put that project under version control for others to share. I won’t explain here how to use version control, but you can look this up in the iTest online documentation.
A project in iTest (represented by a top-level folder in the iTest Explorer view) may be a response map library. (Typically response map library projects are created via a wizard or using the File > New > Response Map Library.) This means that it is a container for response map files – typically for one type of device (or perhaps for a family of similar devices). If you have a family of devices, and some of these devices have response formats that others don’t, you can organize these response map libraries in a hierarchy if you want. But for now, let’s just assume that you have one response map library for each type of device involved in your testbed. Once you put that project under version control, you can share your work by creating new response maps in that project and when you are satisfied with your changes, you can perform a “check in” to upload your changes into the version control server.
Likewise, if you want to pick up any new or modified response maps that others have created, you can “update” your project from version control and you’ll get them into your own workspace.
The recommended way of sharing these kinds of files is via version control. iTest supports a variety of standard version control servers such as Subversion, CVS, etc. (iTest is built on top of Eclipse and can therefore take advantage of any version control system supported by Eclipse itself.)
In order to share your work, you need to make sure those files are in an appropriate iTest project, and you can put that project under version control for others to share. I won’t explain here how to use version control, but you can look this up in the iTest online documentation.
A project in iTest (represented by a top-level folder in the iTest Explorer view) may be a response map library. (Typically response map library projects are created via a wizard or using the File > New > Response Map Library.) This means that it is a container for response map files – typically for one type of device (or perhaps for a family of similar devices). If you have a family of devices, and some of these devices have response formats that others don’t, you can organize these response map libraries in a hierarchy if you want. But for now, let’s just assume that you have one response map library for each type of device involved in your testbed. Once you put that project under version control, you can share your work by creating new response maps in that project and when you are satisfied with your changes, you can perform a “check in” to upload your changes into the version control server.
Likewise, if you want to pick up any new or modified response maps that others have created, you can “update” your project from version control and you’ll get them into your own workspace.
Should we be worried about “best practices” for directory structure and naming conventions in these response map libraries?
You don’t have to worry too much about that. Of course, like any file system, a good organization and appropriate file naming will help a lot as your library grows. Even more important, though, is to get the applicability data in each response map correct. This applicability data is so that iTest can automatically find the appropriate response map, without you having to explicitly choose one for each step in your test case. A little work on the applicability data will make sure that everyone else also gets the benefit of your work.
Tip: In the applicability data, you may want to revise the Applicable Command property to use wildcards so that all forms of a relevant command will match to your response map. For example, if your map works for “show version” but also works for “sh ver” and “show version all”, then you might want to revise the Applicable Command to be “sh* ver*”.
A common problem in a large team is when many people all try to create response maps for the same response – not realizing that there is already a map around for that response (perhaps because its applicability isn’t appropriate for this new variant). If you have more than one map for the same type of response, there is a problem because if the naming of tables and tokens, for example, are not consistent between the two, then a test case may pick up the wrong map and the queries in that test case may refer to things in the original response map but are not applicable for the new response map.
One suggestion in terms of “best practices” is to nominate someone to be the moderator for a given response map library. You can either submit your response maps to this person and they can make sure that the library remains clean. Or, if you want a little more flexibility, you might consider having individuals check in their new response maps, but set the “priority” applicability property to a high number (meaning that it is less likely to be selected if there is another “better” map). They send an email to the moderator identifying the new map, and requesting that it be reviewed. Then it can be “accepted” and the priority can be bumped down so that it will be selected before other new ones.
Anyway, there are many different processes that can work for this. It’s up to you to decide how best to manage it.
A common problem in a large team is when many people all try to create response maps for the same response – not realizing that there is already a map around for that response (perhaps because its applicability isn’t appropriate for this new variant). If you have more than one map for the same type of response, there is a problem because if the naming of tables and tokens, for example, are not consistent between the two, then a test case may pick up the wrong map and the queries in that test case may refer to things in the original response map but are not applicable for the new response map.
One suggestion in terms of “best practices” is to nominate someone to be the moderator for a given response map library. You can either submit your response maps to this person and they can make sure that the library remains clean. Or, if you want a little more flexibility, you might consider having individuals check in their new response maps, but set the “priority” applicability property to a high number (meaning that it is less likely to be selected if there is another “better” map). They send an email to the moderator identifying the new map, and requesting that it be reviewed. Then it can be “accepted” and the priority can be bumped down so that it will be selected before other new ones.
Anyway, there are many different processes that can work for this. It’s up to you to decide how best to manage it.
