Browse Prior Art Database

System and Method for Dynamic Schema and formula/function embed Object Mapping when running Test Disclosure Number: IPCOM000227206D
Publication Date: 2013-May-01

Publishing Venue

The Prior Art Database


1. This article present an system and method for dynamic generated testing codes according to the dynamic schema, developers don’t need to write test codes, it’s high productivity. 2. When there are changes in the class structure or changes on the behaviors of the object constructing, the system can automatically detect the changes and refine the assertion, developers don’t need to involve to change tests. 3. The system and method of present article will construct expected value form the prototype which stored the value used the construct the expected value from the previous correct logic, when the application code changes contain bug, expected value and actual value will not be the same then will detect the bug.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 23% of the total text.

Page 01 of 17

System and Method for Dynamic Schema and formula/function embed Object Mapping when running Test

System and Method for Dynamic Schema and formula/function embed Object Mapping when running regression test

Background & Problem:

One of the important tasks while creating tests is to write verifications about the important attributes of objects. When a user writes the tests manually to verify the value, and when a class has plurality of attributes or attributes of plurality of objects of one class need to be asserted, the following problems are met:

It is very time consuming to write assertions for plurality of fields of complex objects or writing assertions for attributes of plurality objects of the same class.

It will be time consuming to manually changes the tests when there are changes in the class structure such a new field added, deleted and updated in the class, or the application logic to construct the class attributes changes, which will correspond to the expected value changes, then plurality of the previous assertions need to be refined to update the expected value, and it's very hard to maintain.

When the logic changes in the application involve bug, it will hard to detect.

For example, we have 1000 table formed files and each file have 1000 rows, and each row have 1000 columns, And define a Class structure Testcase that have 1000 attributes, and we have an application to create objects of Class structure Testcase from the table formed file, and we design a strategy config file to indicate creating one Testcase object from one row, and one table formed document will create 1000 objects and 1000 table formed file will create 1 million objects and each object has 1000 attributes. And we want to verify all the expected value of the 1000 attributes of the 1 million objects are correct after the changes of the application code.


Page 02 of 17


Page 03 of 17

It's not feasible to write all the attributes validation manually, and according to the method of prior arts 1, we can generate the validation according to the application before the code changes and we generate one test for one object and generate 1 million tests, each test may looks like:
Verify("object1's name's expect value", "actual value")

Verify("object1's description's expect value", "actual value")

Verify("object1's content's expect value", "actual value")

Verify("object1's attribute1000's expect value", "actual value")

The verifications can be junit or nunit assertions or any other ways to verify the result.

And when the application code changes, the application will generate the actual value and compare with the previous value. This way have no problem when the Testcase structure doesn't change, if we add new attributes to the Testcase structure or delete some attributes, it's hard to maintain.

In the following sample the attribute comment is deleted from the Testcase structure and add new attributes attr is added to the Testcase


Page 04 of 17