You may remember
my postwhere I mentioned the technique I like regarding writing precise
Selenium tests.
I believe the good test has double value if it doesn’t verify just the case it is written for, but even catches totally unexpected bugs. How does such test look like?
Several days ago our
Web Grid developers were working on resolving a weird bug in the control. As soon as the new build was ready, I started Selenium tests execution to verify that everything with the build is OK. Some of the tests failed, though, throwing an error that a specified element cannot be found. This appears in several tests that check about element existence in Edit mode of the Grid. Click on ? pencil on the right in the following demo to get an example:
http://www.telerik.com/demos/aspnet/Grid/Examples/Programming/AccessingCellsAndRows/DefaultCS.aspx
Imagine a test that for instance checks about the drop down (GridDropDownColum actually) in the edit form or any other element there:
The test above verifies that the specific element is present in the 2-nd cell of the 1-st row in the edit form table. The same element could be verified by the simpler XPath expression below:
//table[@id='RadGrid1_ctl01_ctl05_mwhere I mentioned the technique I like regardingainTable']//select
You can use Selenium IDE over the demo to verify that (as I explained
here).
So why should I make this check so precise?
The failed tests threw an error because of another element rendered unexpectedly – the check box from GridTemplateColumn (first column in the above grid example). Since the CheckBox is part of the ItemTemplate only (and not EditItemTemplate – see the source from the ASPX tab below the Grid) it should not appear when the Grid is in edit mode. Of course, there was no check like “verify that a CheckBox does not appear as first element in the edit form”, but the precise check in this test (1st row / 2nd cell) actually verifies the exact table structure catching any rendering issues. The test fails since the actual place of the drop down has been changed. Of course no one will find this bug in production – it was addressed immediately as well.
This is just a simple example on the matter, but you can’t imagine all the situations where such precise tests value. So the better our automated tests are the better quality our products offer!
Cheers,
Konstantin