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


Related Posts

Comments

Comments are disabled in preview mode.