Document Properties
Kbid2518F0
Last Modified15-Mar-2016
Added to KB24-Sep-2013
Public AccessEveryone
StatusOnline
Doc TypeGuidelines, Concepts & Cookbooks
Product
  • ICM 7.6
  • ICM 7.7
  • ICM 7.8
  • ICM 7.9
  • ICM 7.10

Concept - Test Model Framework

1 Introduction

To keep the quality high a lot of tests are needed to check the existing code. The Test Model Framework supports the developer to create preconditions for tests.

1.1 Glossary

A test model is a simple helper class, which can be used to create an instance of a special type like business object or a persistent object.

2 Main Concept

The main concept of the framework is to fasten up the setup of a test environment where the tests are executed. Each test model should 'know' by itself what it needs and automatically creates the missing test model.

2.1 Easy Instantiation

To instantiate a new model only the get() method on a static member of the test model is needed. All depending stuff, which is needed for the model is created automatically.

For example there is a test model ProductLineItemTM. This test model creates a ProductLineItem instance. It automatically creates the corresponding objects (basket, user, product, price, address, warranty, etc.) that are needed. The developer does not need to know all the necessary objects, which are required for that test model.

2.2 Compendium of Test Models

The different occurrences of the test models are just static members in that test model class.

2.3 Caching, Reusing

When a test model is created the first time it uses an internal create() method. The test model stores the created model internally and later calls will just return this model.

Take care, that these static members are not changed during a test.

2.4 Simply Clean Up

After the test, a simple call of TestModel.clearAll() removes all created test models. Please use it in combination with setAutoCleanup(true). The method clearAll() only removes the internal references, but will not remove the models from the data base.

2.5 Simply Extension or Creation of New Test Models

If you want a different instance of a test model, which is not defined as a static member of that class, add another static member. All the information for this test model should be defined via the constructor. When changing the logic it is recommended to extend the test model and create an inner class. Thus, you can collect all different test models (static members) of that type in one class.

You can also create new test model for a new model. For that purpose, extend the class AbstractTestModel<T>. It is abstract and you must implement the abstract method T create(). The generic T is the type of the model you want to create with that test model.

Define one or more constructor to set the attributes of the test model. In the create() method you can create the model with the help of the attributes, given by the constructor.

2.6 Organization Structure

Every test needs exactly one test model of OrganizationStructureTM. It can also indirectly be created by other test models like the BasketTM.

There is only one step needed for each test class to set up the needed cartridges at the organization structure. Call the method (e.g. , OrganizationStructureTM.organizationStructure1.setTestCartridges(yourTestCartridgeList). This method expects a array of strings representing the cartridges.

3 Class Diagram

Class Diagramm Test Model Framework

The class diagram is very simple. Every test model inherits from AbstractTestModel. The AbstractTestModel handles the creation of the model. Therefore, it calls the create() method, which must be implemented by the test model. It also caches the created model internally.

The class TestModel is implemented by the AbstractTestModel. If get() is called, then the internal create() method is called, which creates the model. Every other method call of get() delivers the cached model. The method clear() removes the cached model. So the next call of get() creates a new model.

The static method clearAll() removes all cached Models for every test model instance. This method should be called at the end of a test.

3.1 Cartridges

At the moment all existing test models belong to the catridge sld_ch_b2c_base_test. Basically, it is intended to move a test model to the corresponding cartridge. As an example, BasketTM will be moved to b c_basket_test.

The interface TestModel and the class AbstractTestModel are located in the cartridge etest.


 

Disclaimer

The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources
Support Tickets