In my webapp, there are multiple screens that have common webElements. I want to assert that all these common elements exist on each page. But I don't want to put all my asserts into a single utility function that will abort halfway through if one assert fails. I want to have individual test cases for each assert and run that set of tests in multiple test classes (one for each page).
I read that inheritance is a bad idea because then you have to dig deeper than the im开发者_如何转开发mediate test class to see all the tests that are being run. But at the same time, I don't want to maintain multiple copies of tests that are common across pages.
The same rules apply to test development that apply to the rest of your development, you do what you and your team find the easiest to understand. You have the following options:
Inheritance: defining tests in a parent class. I have used inheritance with JUnit tests, including tests in the parent class. This worked and worked well, and the main advantage was that it saved duplicating code. Disadvantages: you have to look in multiple places for your tests. When you double click on the test name in the Junit view in Eclipse, it takes you to the parent class, which is sometimes confusing.
Have a class specifically for testing the common features of your pages, lets call it PageTest. PageTest would use @Parameterized to test all of the pages. Advantages: All of your tests for common stuff is centralized. Disadvantages, if you add a page, you need to add the page to the list. You can avoid having to add stuff to the list by using reflection, if that's possible. We had one set of tests which searched the classpath for any class which inherited from a certain class (struts Action in this case) and ran some tests on that class.
Of the two options, I would choose the former because it's less work; everything for a single page is on one place, and you never 'forget' to test the common elements. But it's your project, do what works for you.
精彩评论