TestCaseImportRestriction

Since: AludraTest 2.7.0

AludraTest Test Case Classes must only use some types of classes. This shall ensure good test case design - do not perform any low-level operations in the test case classes, but bundle them in component classes. Good Test Case classes can completely replace a textual description of the Test Case.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.testcase.TestCaseImportRestriction

This rule has the following properties:

AWLAbstractNameForAbstractClass

Since: AludraTest 2.7.0

Only abstract ActionWordLibrary classes shall be named "Abstract". This avoids developer and reviewer confusion.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.awl.AWLAbstractNameForAbstractClass

AWLNoNonFinalStaticAttribute

Since: AludraTest 2.7.0

Do not use non-final static attributes (class attributes) in ActionWordLibrary functions. This would imply a class-wide state, and ActionWordLibraries should at most hold an instance-local state to avoid strange side-effects which could depend on test timings etc.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.awl.AWLNoNonFinalStaticAttribute

AWLNoTestCaseAttribute

Since: AludraTest 2.7.0

ActionWordLibrary classes should not have an attribute of a Test Case type. This is almost always an error or really bad component design.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.awl.AWLNoTestCaseAttribute

AWLNoPublicStaticMethod

Since: AludraTest 2.7.0

There is no need for ActionWordLibrary classes to provide public static methods. There is no class-wide information which should be made accessible this way.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.awl.AWLNoPublicStaticMethod

AWLActionMethodReturnAWL

Since: AludraTest 2.7.0

All public methods of an ActionWordLibrary class must return an ActionWordLibrary type (but not necessarily the same type). This allows for fluent programming and reflects the possible state change of the System under Test by the executed operation. Non-state changing methods should still return a new object of the same type instead of returning "this".

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.awl.AWLActionMethodReturnAWL

AWLActionParameterDataClass

Since: AludraTest 2.7.0

All actions (public methods) must operate on Data objects, if parameters are required for the action. This enforces the creation and use of Data classes, which allows for easier parametrization of Test Cases, and avoids hidden encoding of values.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.awl.AWLActionParameterDataClass

PageClassNamingConvention

Since: AludraTest 2.7.0

All classes which extend the class org.aludratest.service.gui.web.page.Page should have a name ending with "Page". This increases code readability.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.page.PageClassNamingConvention

PageClassSimpleNameMustBeUnique

Since: AludraTest 2.7.0

The simple name of a Page Class should be unique. This makes the possible integration with grapical Test Case editors easier.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.page.PageClassSimpleNameMustBeUnique

PageNoPublicAttribute

Since: AludraTest 2.7.0

Pages should not expose any public fields. Page objects are, at best, completely stateless, as each and every of their public methods return a new Page object. Even if some state is required for whatever reason, public fields allow for state changes without calling an action method, which is very error-prone.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.page.PageNoPublicAttribute

PageActionMethodReturnPageObject

Since: AludraTest 2.7.0

Every public method of a Page class must return a Page type (but not necessarily the same type). This allows for fluent programming and reflects the possible state change of the System under Test by the executed operation. Non-state changing methods should still return a new object of the same type instead of returning "this".

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.page.PageActionMethodReturnPageObject

PageUtilityClassStructure

Since: AludraTest 2.7.0

Page Utility classes (extending base class org.aludratest.service.gui.web.page.PageUtility) must only have public static methods and a hidden constructor. This ensures that the methods are stateless helper methods, e.g. encapsulating recurring code segments.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.page.PageUtilityClassStructure

PageUsageRestriction

Since: AludraTest 2.7.0

Page classes must only be used by Test Cases and Page related classes. This enforces that e.g. no UIMaps reference Page classes, which would be an indicator for bad component design.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.page.PageUsageRestriction

PageHelperUsageRestriction

Since: AludraTest 2.7.0

Page Helper classes (extending base class org.aludratest.service.gui.web.page.PageHelper) must only be used by Page and other PageHelper classes. This ensures that the reusable code designed to be used by Pages is not used in UIMaps or Test Cases, which would be a break in code design.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.page.PageHelperUsageRestriction

PageUtilityUsageRestriction

Since: AludraTest 2.7.0

Page Utility classes must only be used by Pages, Page Helpers, and other Page Utility classes. This ensures that the reusable code designed to be used by Pages is not used in UIMaps or Test Cases, which would be a break in code design.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.page.PageUtilityUsageRestriction

PageImportRestriction

Since: AludraTest 2.7.0

Pages must only use classes of type Data, UIMap, Page, PageUtility, PageHelper, GUIComponent, and AludraService. Although this is already relatively broad, this ensures that e.g. special code dealing with complex classes is put into PageUtility classes, making it reusable from the start.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.page.PageImportRestriction

UIMapNamingConvention

Since: AludraTest 2.7.0

UIMap classes should have a name ending with "UIMap". This increases code readability.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.uimap.UIMapNamingConvention

UIMapNoPublicField

Since: AludraTest 2.7.0

UIMaps must not expose any public fields. UIMaps should be completely stateless, as every method invocation should create a new GUIComponent object. The only fields which are allowed in a UIMap class are static String constants being used e.g. as XPath strings for Locators. These constants should never be public.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.uimap.UIMapNoPublicField

UIMapNoInstanceField

Since: AludraTest 2.7.0

UIMaps must not have any non-static fields (not even private ones). This shall enforce that UIMaps are always stateless, as every method invocation should create a new GUIComponent object.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.uimap.UIMapNoInstanceField

UIMapMethodReturnComponent

Since: AludraTest 2.7.0

Every public method of a UIMap should create and return a GUIComponent. Other method types should not be used in a UIMap.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.uimap.UIMapMethodReturnComponent

UIMapUtilityClassStructure

Since: AludraTest 2.7.0

UIMap Utility classes (extending base class org.aludratest.service.gui.web.uimap.UIMapUtility) must only have public static methods and a hidden constructor. This ensures that the methods are stateless helper methods, e.g. encapsulating recurring code segments.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.uimap.UIMapUtilityClassStructure

UIMapUsageRestriction

Since: AludraTest 2.7.0

UIMaps must only be used by UIMap related and Page related classes. This enforces good component design and prevents e.g. Test Cases from accessing GUI components directly (use high level methods of Page classes instead).

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.uimap.UIMapUsageRestriction

UIMapImportRestriction

Since: AludraTest 2.7.0

UIMap classes are only allowed to use these types of classes: GUIComponent, Locator, UIMap, UIMapHelper, UIMapUtility, AludraGUI. This enforces good component design and prohibits e.g. "back-access" to Page objects.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.uimap.UIMapImportRestriction

UIMapHelperImportRestriction

Since: AludraTest 2.7.0

UIMapHelper classes (extending base class org.aludratest.service.gui.web.uimap.UIMapHelper) are NOT allowed to use these types of classes: PageHelper, PageUtility, ActionWordLibrary, AludraTest. This enforces good component design.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.uimap.UIMapHelperImportRestriction

OnlyUIMapsConstructGUIComponent

Since: AludraTest 2.7.0

Only UIMaps are allowed to create new instances of GUIComponent objects. This makes sure that the knowledge on how to create these components is bundled in UIMap classes only.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.guicomponent.OnlyUIMapsConstructGUIComponent

DataClassNamingConvention

Since: AludraTest 2.7.0

Data classes (extending base class org.aludratest.dict.Data) should have a class name ending with "Data". This increases code readability.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.data.DataClassNamingConvention

DataClassSimpleNameMustBeUnique

Since: AludraTest 2.7.0

The simple name of a Data Class should be unique. This makes the possible integration with grapical Test Case editors easier.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.data.DataClassSimpleNameMustBeUnique

DataClassNoArgConstructor

Since: AludraTest 2.7.0

Data classes must have a public no-arg constructor. This is important, as instances of data classes are created by the framework, e.g. when loading Test Case parameters.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.data.DataClassNoArgConstructor

DataClassImplementToString

Since: AludraTest 2.7.0

Data classes should implement toString(). This string representation is used in the Test Case log.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.data.DataClassImplementToString

DataSimpleAttribute

Since: AludraTest 2.7.0

All fields of a Data class should be of type String, another Data class, or Collection (or a subtype) of a Data class. This ensures that all Data is (in the end) String-based and can easily be read from text-based input (e.g. files). This also allows Test Cases to use invalid input for e.g. Date fields.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.data.DataSimpleAttribute

DataNoCircularGraphs

Since: AludraTest 2.7.0

No circular graphs may exist between the properties of two Data classes. This would possibly be an endless recursion and, in every case, prohibit a "flattened" representation of the Data contents (e.g. with a dot-based notation).

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.data.DataNoCircularGraphs

DataNoStaticAttributes

Since: AludraTest 2.7.0

Data classes must be kept as simple as possible (simple data containers). There should not be any static attributes carrying any class-wide information.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.data.DataNoStaticAttributes

DataAttributeMustBeAccessible

Since: AludraTest 2.7.0

Every Data field must have appropriate Getter and Setter methods. This allows setting the field values from the outside via the framework. Please notice that the same logic as used by Eclipse applies. Just press Ctrl+Space in your class body to see if there are any "set..." methods still offered by Eclipse to be created as Setter methods - implement these methods using this technique.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.data.DataAttributeMustBeAccessible

DataFieldsMustNotBePublic

Since: AludraTest 2.7.0

Data fields must not be public. Create simple Getters and Setters for them, e.g. using Eclipse's mechanisms. This implements the official Bean logic for this class and allows easier integration with external tools and, in the future, a graphical IDE editor.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.data.DataFieldsMustNotBePublic

DoNotCombineBeforeAndAfter

Since: AludraTest 2.7.0

Do not use annotations Before and After on the same method. Split into two methods, if required.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.annot.NonCombinableAnnotations

This rule has the following properties:

DoNotCombineSequentialAndParallel

Since: AludraTest 2.7.0

Do not use annotations Sequential and Parallel on the same class or method. It does not make any sense.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.annot.NonCombinableAnnotations

This rule has the following properties:

NoTrailingCommaInAnnotationArray

Since: AludraTest 2.7.0

Do not end array initializers in Annotations with a comma. There is a javac bug around unable to compile (ignore) these.

This rule is defined by the following Java class: org.aludratest.codecheck.rule.pmd.annot.NoTrailingCommaInAnnotationArray

			
@Suite(value = { MyTest.class, YourTest.class, })
public class MySuite {
}