Open your favourite text editor and add the following:
then save the file into the Madcow 2.0
tests folder as
Now create a new file with the following:
and save the file into the Madcow 2.0
mappings folder as
Then open up a command prompt or terminal window on Mac and type…
You should see a lot of things start to happen. Don’t worry this is just your test running.
It is running the above
GoogleTest.grass file, which will basically do the following steps:
Note: Each one of those steps listed here directly correlates to the step in the testcase.
Once completed you will then want to see the results of your test. To do this simply open the
index.html file in the
results\madcow-results folder in your browser of choice.
or run at the command line in Mac
or in Windows
It should look similar to this:
Here you can see that it all passed successfully. To see further details about the test run click on the “GoogleTest” link and you should see more details step-by-step results showing what the Madcow test did.
The main principle behind Madcow is to easily specify an element in your web application and manipulate it and make assertions on it. To specify an element simply refer to its html ID on the page. For instance the html:
can be found and used in your test by:
This will find the element with id
searchBox, which is an input element and then set its value to
"Find me the cheapest phone".
But what if the element you are trying to test doesn’t have an ID? Madcow has a simple mapping mechanism that map xpaths, names or text to nice IDs you can use in your tests.
So what was that
google.grass file for then?
By default Madcow 2.0 will use the IDs in your html to find elements. But often these are ugly or non-existent. The google front page is a good example of this. So we will need to map the search box and search button to nice names to use them.
Madcow looks for files in your
mappings directory named
This is why in the original example we created a new file call
google.grass with the following lines:
The Google front page has an input box with no ID but has a name attribute of the value “q”, like this:
In our mappings file we mapped it to the label
searchBox by writing:
We do the same thing for the
searchButton. This then allows us to reuse these “mappings” in your test cases by following the mappings convention of filename_item, or in our example
To tell madcow to open up a browser and navigate to your web app in your test simply run the invoke step
Now we want to do a search for the About 4impact page.
.value command sets the value of the input box to be
4impact. And the
.clickLink command clicked on the search button, which in this case, submitted the google search and displayed a new page with the search result. These items after the
. are known as Madcow operations.
Finally we want to click on the About 4impact link. We know that the link will be in the search results page with so in our
google.grass file we can map an xpath expression to the
About 4impact google search result.
So let’s click that link
And that’s it for your new “About 4impact” google search test! Here is the full listing.
The simplest form of tests in Madcow 2.0 is in a GRASS file. Simply create a test ending with
MadcowTest.grass such as
GoogleMadcowTest.grass in the
test directory and Madcow will automatically find and run it. These grass files are the same as properties files used in Madcow version 1.
You can only have one test in a single grass file.
A powerful feature of Madcow is the ability to load other properties files in your tests to get greater reuse. To do this you use the
The import command will look for properties files, in this case
LogoutActions.grass and insert the contents of these files into the script. See Templates for more information.
Madcow allows the use of data parameters, to specify reusable pieces of test data throughout a test. This allows a test to be data driven rather than being bound to a specific set of data throughout the test. The data parameters are used through the @ notation. See Data Parameters for more information.
To add single line comment to a test simply prepend a # to the front of the line.