In my previous articles Design Grid Control Automated Tests Part 1 , Design Grid Control Automated Tests Part 2 , Design Grid Control Automated Tests Part 3 I started a mini-series about writing proper grid control's automated tests. This will be the fourth final part. Here I am going to talk about how we can reuse to the maximum extent the logic that we already have created for asserting the controls.

Test Cases Reuse Problem

The test case tests that the order id's column filter is working as expected. In real-world applications many times we have grids that display almost the same data in a little different manner. For example, you can have one grid that displays the expired orders and one for the successfully completed. Both grids have almost identical columns. However, you need to automate both grids because usually a custom code is added to enable the desired behaviour such as filtering by status, etc.

Expired Orders Grid

Successfully Completed Orders Grid

Advanced Reuse Tactics

We will have almost identical tests but sometimes some of the columns might be missing or new columns might be displayed so we need a solution where we can configure which column to be verified or not. So my idea is to create different assert classes for each column. This way through a composition in your tests you can design-time choose which column to be asserted or not.

While ago when we were working on the first version of the BELLATRIX test automation framework, I did this research while I was working on a similar feature for our solution.

IGridPage Interface

Until now some of the tests worked with a single page or with the kendo grid controls directly. Nonetheless, in order to make the column's asserter more generic, it should work with an interface. Because of that, I have created the new IGridPage interface.

All pages that contain grid control should be implemented it. This way your columns asserters can be used against the different pages and their grids.

This is how our first grid's page looks like.

Reuse Grid Control's Helper Methods As you can recall from the previous articles from the series, we needed different helper methods like WaitForPageToLoad, Until, GetAllItemsFromDb, etc. They were placed inside the test class as private methods. However, if we have different asserters and move the whole logic in them, we will need these methods for the different test cases. By cause of that, we can move them to a new base asserter class that all other columns' asserters are going to derive from.

Concrete Grid Column Asserter's Implementation The next part of the refactoring is to create the different column asserters. Below you can find the concrete asserter for the OrderId column. It derives from the GridColumnAsserter class.

If you recall the code of the examples from the previous articles, you will notice that the above code is almost identical . The main differences are that the helper methods are placed inside the base class and that the different methods are not marked as MSTest test methods. Also, the grid control is accessed through the IGridPage interface so that we can reuse the test cases for different grids. The asserters for the rest of the columns are similar to this example so I am not going to publish their code. If you are interested you can download the fully working examples at the end of the article.

Grid Column Asserters in Tests Grid Control's Tests Setup

This is how looks the setup of the refactored version of the grid control's tests.

You assign the concrete implementation of the concrete grid's page to the IGridPage interface variable. Then you initialize only the required grid columns' asserters. This means that if for example the ship name column is not present on this grid, you won't include its asserter. You can have different combinations of column asserters depending on the columns' combination in the currently tested grid. Grid Control's Tests