When i saw the mail from nags saying
” Can somebody evaluate it and send me back the results. It was done by Yazhini, long time back, but I could not check them.”
even i didn’t think i will write the test cases for file-roller that night. I just wanted to see the code and maybe make a comment. After seeing the code, i felt really sorry for file-roller 😛 . Yeah now it looks crazy, but not at that time. When evolution, gedit and other applications have new new scripts, why should file-roller have the old test scripts. 🙂
So wrote the test cases for file-roller according to the new file-roller and new LDTP.
I will write about what all changes should be made while changing the scripts, so that it will be useful for someone who might change the code for other applications like gcalctool, bugbuddy, gnome-font, gnome-search-tool, gdf etc.
The files can be downloaded from
here. Just take care that you don’t have a file called ldtptestarchive.tar.gz in your home folder. Apart from that, you need to change the run.xml . I tried the scripts in solaris but setcontext didn’t work properly there :(. Have to check that soon.
1. Names of objects in applications.
This has changed a lot, especially in the frame names. In the old scripts for file roller, it will be like
selectmenuitem (‘ArchiveManager’,’mnuHelp;mnuAbout’)
But according to the new LDTP, it is better to have
selectmenuitem (‘frmArchiveManager’,’mnuHelp;mnuAbout’)
Note the way the window name is mentioned in the new version. If has the prefix
frm in that. The older one might still work but it is better to change soon. The prefix for each and every object can be seen in a file called
remap.c in src folder. The function
get_object_info (Accessible *accessible) in that file is the one which can give information about the prefix for each object type.
Apart from this, a ldtp function called
getobjectlist () is also useful. Another utility called appmap is also useful in this case, but it is better not to use it, since the appmap is obsolete and latest changes are not incorporated into that. I think getobjectlist is the best solution. A tool called at-poke is also very useful to find the objects and object types inside an application.
2. Runner XML.
In the old scripts a python file used to call each and every other test case files using exec(). In many cases this main python file will be the name of the application. For example, check the file-roller.py
#To create a new archive
log (‘Create New Archive’, ‘teststart’)
execfile (‘create-archive.py’)
log (‘Create New Archive’, ‘testend’)
time.sleep(2)
#To open an existing archive and extracing them.
log (‘Open Extract Archive ‘, ‘teststart’)
execfile (‘open-extract.py’)
log (‘Open Extract Archive’, ‘testend’)
So this way many scripts are tested from the a single python file. In the new test files, the concept of
ldtprunner and
runner xml is introduced. The links mentioned there are the best place to learn about runner XML. Just for the sake of completion let me add a sample runner xml for the above code here
<ldtp>
<logfileoverwrite>1</logfileoverwrite>
<logfile>log.xml</logfile>
<group>
<script>
<name>create-archive.py</name>
<data>fileroller.xml</data>
</script>
<script>
<name>open-extract.py</name>
<data>fileroller.xml</data>
</script>
</group>
</ldtp>
Scripts can be easily added, removed and grouped using the runner.xml .
3. waittillguiexist() and waittillguinotexist().
The two functions are really useful if you want your code till an object appears or disappears. The docs for these two functions explains the usage clearly. The old test code will have an approximate time.sleep() in their code. A better and proper solution is to incorporate waittillguiexist() and waittillguinotexist() and remove the unwanted time.sleep()
4. LDTPExecutionError :
The old code just has an except block which can catch any exception that occurs. It is better to handle the LDTPExecutionError separately and other errors in a different manner. A typical except block in the new script will be like
except LdtpExecutionError, msg:
msg = ‘open-extract test case failed’
log (msg, ‘error’)
raise LdtpExecutionError (msg)
5. Data XML.
One of the most important thing in LDTP, which adds great flexibility to the test cases. The filenames and other variables need not be hard coded.
A single XML (generally called the data XML) can have all the details like the filenames, paths used in a test case and these value can be extracted from the XML file. Thus even the arguments passed to the test cases can be changed using a data XML.
6. Appmap file.
Since now in LDTP , the remapping of the objects in application is done automatically, there is no need to use
initappmap() or
remap() anymore. So there is no need to have a default map file for each application.
Therefore you can remove the following piece of code if you find it in your test case.
if len (sys.argv) == 1:
if os.access (‘./file-roller.map’, os.F_OK | os.R_OK) == 0:
print ‘Appmap path missing’
sys.exit(0);
else:
appmap_path = ‘.’
else:
appmap_path = sys.argv[1]
initappmap (appmap_path + ‘/file-roller.map’)
“After seeing the code, i felt really sorry for file-roller :P”
Very funny!!
@ya : lol, yeah , see the code for yourself 😛 .
Have you ever read this ???
“I spent a minute looking at my own code by accident. I was thinking ‘What the hell is this guy doing?’ “:P
your blogs are not fit to be read by humans.