Asserts on Objects

<asserts><assert id="myId" type="my.class.Type" hint="myParseHint" action="MYACTION">...</assert><asserts>

For implementing a solid support of assertion features the JUnit-Addons library from Sourceforge is added as utility archive under the terms of the Apache Software License. The possibilities of defining asserts is mapped directly on the assert methods as defined inside of JUnit and JUnit-Addons. The following actions are implemented for now:

Valid Assert Actions
isEqualMaps to JUnit Assert.assertEquals().
isNotEqualMaps to JUnit-Addons Assert.assertNotEquals().
isSameMaps to JUnit Assert.assertSame().
isNotSameMaps to JUnit-Addons Assert.assertNotSame().
isNullMaps to JUnit Assert.assertNull().
isNotNullMaps to JUnit-Addons Assert.assertNotNull().
isTrueMaps to JUnit Assert.assertTrue().
isFalseMaps to JUnit-Addons Assert.assertFalse().
isContainedInMaps to JUnit-Addons Assert.assertTrue(((Collection)obj).contains(actual)).
isNotContainedInMaps to JUnit-Addons Assert.assertFalse(((Collection)obj).contains(actual)).
used for java.lang.Compareable
isLTactual is smaller as expected.
isNotLTactual is not smaller (greater or equal) as expected.
isGTactual is greater as expected.
isNotGTactual is not greater (smaller or equal) as expected.
isInRangeactual is in specified range according to Comparable rules.
isNotInRangeactual is not in specified range according to Comparable rules.

The possibility of defining asserts inside of xml gives two advantages over directly using the obj tag and plain %junit; asserts inside the code.

  • You clearly distinguish between object definitions and assert information.
  • You can use these definitions for reports on test execution and what was checked during test. And therefore can provide an active specification document of your class under test.
All object structures that can be defined under <objs> can be used for defining expected objects inside of <assert>. Just remember the importance of overwriting the equals() and hashCode() methods of the objects to make them even more valuable to use under JUnit / DDTUnit.
Here is a short example:
<assert id="complete" action="isEqual" type="junitx.ddtunit.resources.SimpleVO">
  <stringValue>My Text</stringValue>
Which is interpreted like this:
Check an actual object provided during test execution against the expected object stored under assert@id complete and assert@type junitx.ddtunit.resources.SimpleVO.
The DDTUnit testmethod would look something like this:
public void testMyService(){
  SimpleVO simpleVO = MyServiceUnderTest.getSimpleVO();
  addResultToAssert("complete", simpleVO);
To make this work right the object simpleVO must implement the methods equals() and hashCode() to meet a clear expectation of an equality comparison of this type. The same holds true for the use of JUnit as well.

To be complete: There are three methods defined under DDTTestCase

The first method provides information for assertions at the end of the JUnit/Java testmethod execution.
The second and third are used for direct evaluation of the defined assertion. If the boolean mark is set, no double validation of this assertion will be done at the end of the test method.

As the class DDTTestCase is a direct derivation of JUnit TestCase it is possible to use all assert methods of junit.framework.Assert directly in the code. It is also possible to use your own assertion extensions in the testmethod.
Because the provided testdata change, so do the required assertions.
As a rule of thump use this kind of assertions every time you have correlation with parameter data of xml resources. This provides information about the contract or specification you want to test.

What are JUnit assert methods good for?
Every time you want to check pre or post conditions of a data centric check use JUnit assert methods. These should be used similar to the Java assert extension. For example if you want to check the result of a customer list returned by a business function.

  • First check if the list is not null by using JUnit assertNull(...) .
  • Evaluate the correct list content by using DDTUnit assert definition.
As by using every rule it is up to you to select the appropriate solution.

The assert action isContainedIn is used to validate if an object is in a specified set of objects. To define such an assert you must specify a Collection containing expected values. For example:

	<assert id="testResult" type="java.util.Vector" hint="collection"
		valuetype="boolean" action="isContainedIn">

The assert action isInRange is used on java.lang.Comparable datatypes to validate if an object is in a specified range. To define such an assert you proceed as in the following example.

  <assert id="result" type="range" action="isInRange">
    <start type="long">4711</start>
    <end type="long">4759</end>
For now you must specify start@type and end@type. This behavior will be replaced by assert@valuetype in future.
By default the end points of the interval are included in the specified range. To exclude one end of the range specify the appropreate tag <startIncluded> or <endIncluded>.
sf logo