Test classes with common behavior

Question

I have to write some integration test classes in the Hybris Commerce Suite and most of them share a common behavior to set up the system (Site, Store, Catalog, Country, ...) or to perform some common action like create a customer.

I created an abstract class that perform all the initialization with constant values in the @Before method and with some common methods like createDefaultCustomer().

All my test classes inherit from this class.

The constant values are separated in different constant classes like

abstract class AbstractTest {
  protected static final class USER_CONSTANTS {
  };
  protected static final class CATALOG_CONSTANTS {
  };
  protected UserModel createDefaultUser() {
  }
}

Now, in order to test, in my subclasses i can do

createDefaultUser();
UserData userData = userFacade.getUserById(USER_CONSTANTS.ID);
assertEquals(USER_CONSTANTS.ID, userData.getId());

If I don't do this there is a lot of duplication in test classes.

My doubt is whether this is acceptable because the abstract class tends to be long and rich of methods or I need to change the design. I would to avoid the creation of separate classes for each group of constants.

score 0 · Answer 1 · answered Sep 11 '13 at 18:59

0

How about creating it as a BaseTest abstract class (just like your AbstractTest) with all the necessary features you will need in all of your tests. Then you can simply extend your abstract class to inherit all of its properties, and write any additional functionality based on your specific tests. Something like DefaultUserTest extends BaseTest { protected UserModel createDefaultUser() {} }

answered Sep 11 '13 at 18:59

Farlan

1,860
2
28
37

If you mean that realTest extends DefaultUserTest that extends AbstractTest, I might have problems when a class needs two separated functionality. For example, a test for the products most viewed by a user needs to have a createDefaultUser() and createDefaultProduct() – Vincenzo Sep 11 '13 at 19:18
No , I mean you may create a baseTest and then let your realTest extend that. Of course the real test would in turn compose the classes such that you could test createDefaultUser() and createDefaultProfile() in one test case. – Gyanendra Dwivedi Sep 11 '13 at 19:51
Ah ok. This is what I am currently doing, all test classes inherit from AbstractTestClass. The problem is that AbstractTestClass tends to be very long and heterogeneous. – Vincenzo Sep 11 '13 at 20:01

score 0 · Accepted Answer · answered Sep 11 '13 at 19:09

I think its perfectly ok to use a base test class for your common code and then extending that in each of the Test class. In fact the test strategy should be in-line with the design of the project code. I am sure that your project module would have some common code as well, your common test section basically map to those functionality of project code.

I have done similar design in couple of projects without any issue.

So, whenever your project has a change in common functionality, it would affect test case in common test class, while specific changes go with specific test class.

In the project code all data values are saved in database and a module can call services (i.e. UserService, ProductService...) to obtain models and perform some logic. I'm trying to "simulate" this database because if I put real data than the test is too data-dependent and less flexible — Vincenzo, Sep 11 '13 at 19:47

Test classes with common behavior

2 Answers2