Hi everyone!,
Here is a brief summary of my work last week.
I started with implementing progress bars, now the progress within a testsuite and the overall progress are reflected by two text lines of form (X of XX tests), In addition the progress within a testsuite is also shown graphically as progress bar, which gives a cool look ;).
Next I moved on to some more improvements in GUI as suggested by Eugene. There existed a button to select all tests at once but no such button to do the reverse. This was balanced by making the same button do both the jobs, i.e if number of selected tests is more than deselected ones, it shows “Deselect All”, “Select All” otherwise. Other improvements included, modifying the GUI texts, and some formatting.
Next, their were tests which when ran in interactive mode showed no activity, code was added to make them display the information about what they are working with.
Finally, I started on enabling the testsuite and test selection using a config file. Initially, I rolled out my custom implementation to read and parse config files, later i figured out that this could also be done using the ConfigFile class. So I switched my implementation to make use of that class.
Now we have a layout-like this:
[Global]
# Global-parameter-name value pairs here
isSessionInteractive=true
[Testsuite]
# Decides if testsuite itself is enabled or not
this=true
# Tests within the testsuite go here
dummyTest=true
This does two useful things:
- It saves your configuration each time you customize and remembers it, so that you don’t have to customize every time if you needed a particular customization.
- One can also manually edit t his file to affect exactly which tests of a particular testsuite be executed.
Next, I also worked on writing a testcase for cursor-trails in GUI bug.
The problem was if the shake offset is set, and then GUI is shown, cursor leaves trail in GUI and its very difficult to click any button. I first reproduced this problem which quite ended up as a test for it.
I have an offset of 25 pixels set and I then prompt GUI dialog to verify if the user sees a trail or not, If there are no trails, user will probably click the “No” button on right, if there be trails, clicking any button would be difficult and user may end up pressing “return”, which is interpreted as “Yes” i.e trails were there.
Finally towards the end, I enabled the logging feature.
Now testbed outputs are logged with more details, and are also produced on stdout with lest explicit details.
One can provide his own logDir/logFile, by default log files are “testbed.log” produced in game-data directory.
Next week I plan to take on sound subsystems. This is probably the last subsystem to be tested.
I want to do all this quick so that I could get some time to modify things as mentors want them to ;).
—
Neeraj