Table of contents

1. AlterationIntegrationTest
2. AlterationUnitTest
3. AmbiguousViewModelTest
4. CdnCssTest
   1. Legacy configuration
5. ConflictingTemplateTest
6. ContentLifecycleEmbeddedTest
7. DuplicateAlterationsTest
8. DuplicateClassFileTest
9. JobStatusTest
10. InternalNameUniquenessTest
11. ModificationFieldInternalNamePrefixTest
12. ModificationInvalidAnnotationTest
13. NoAfterCreateOutsideModificationsTest
14. NoFinalFieldsInRecordsTest
15. NoOverrideEqualsInRecordsTest
16. NoOverrideHashCodeInRecordsTest
17. NoShadowedClassesTest
18. ObjectTypeAnnotationValidationTest
19. PageViewsNotIncludedInOtherViewsTest
20. RecordableCollectionGetterTest
21. RecordableHasNullaryConstructorTest
22. RichTextElementPreviewTest
23. RichTextElementUniqueTagTest
24. RichTextElementUnitTest
25. SubstitutionUnitTest
26. SuggestibleTest
27. ThemeCompatibilityTest
    1. Legacy configuration
28. ValidIndexedMethodsTest
29. ValidNonIndexedMethodsTest
30. ValidObjectFieldTypesTest
31. Deprecated tests
    1. AlterationClassAnnotationProcessorTest
    2. AlterationFieldAnnotationProcessorTest
    3. AlterationFieldsExistTest
    4. EnhancementViewModelTest
    5. NoAbstractSubstitutionTest
    6. NoAlterationMethodsTest
    7. NoSubstitutionInterfacesTest
    8. SearchableLinkableTest
    9. SearchablePromotableTest
    10. SingleSubstitutionTest
    11. SubstitutionIsRecordTest
    12. ViewModelAbstractMethodErrorTest

AlterationIntegrationTest

Adding fields to an Alteration that do not already exist in the target class has no effect, and it is likely that the intent was to create a Modification instead.

To exclude specific Alteration classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.AlterationIntegrationTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/AlterationIntegrationTest.ignored.txt.

Additionally, “ignored” files for AlterationFieldsExistTest (which this test replaces) are also honored.

AlterationUnitTest

This unit test checks for four common mistakes:

1. Alteration can be used to add annotations to an existing model class. The annotations added must have an associated ObjectType.AnnotationProcessorClass to be compatible with Alteration.

2. Alteration can be used to add annotations to the fields of an existing model class. The annotations added must have an associated ObjectField.AnnotationProcessorClass to be compatible with Alteration.

3. Alteration can be used to add annotations to a Global modification (i.e. a Modification<Object>) but only field annotations are supported, as there is no ObjectType instance for the associated ObjectType.AnnotationProcessorClass to work with. (Introduced in version 1.3.0)

4. Methods on an Alteration class will be completely ignored, and it is likely that the intent was to create either a Modification or Substitution instead.

To exclude specific Alteration classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.AlterationUnitTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/AlterationUnitTest.ignored.txt. Additionally, “ignored” files for AlterationClassAnnotationProcessorTest, AlterationFieldAnnotationProcessorTest, and NoAlterationMethodsTest (which this test replaces) are also honored.

AmbiguousViewModelTest

This integration test fails the build if any View/Model combinations have multiple ambiguous ViewModel implementations. This prevents the common error in logs like

WARNING: Found [2] conflicting view model bindings for model type [brightspot.core.gallery.Gallery] and view type [com.psddev.styleguide.core.promo.PromoView]: [brightspot.dummy.RedundantPromoViewModel, brightspot.
core.promo.PromotablePromoViewModel]

To exclude specific ViewModel, View Interface, or Model classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.viewmodel.AmbiguousViewModelTest, “ignored” filename is ./src/test/resources/brightspot/viewmodel/AmbiguousViewModelTest.ignored.txt.

CdnCssTest

This unit test checks enumerated CSS files in a theme or the root styleguide to ensure that all URLs contained in url() directives actually exist.

All CSS files need to be manually specified in the bundle’s build.gradle:

bundle {
    cdnCssFiles = [
        'path/to/All.min.css',
        'path/to/another/File.css'
    ]
}

Legacy configuration

The legacy Brightspot Gradle plugin automatically configures all themes to look for an All.min.css in the styleguide.

CSS files can be manually specified with a comma-separated list in site/build.gradle like so:

test {
    systemProperties.put('theme.my-theme.cdnCssFiles', 'styleguide/All.min.css,styleguide/bootstrap.min.css')
}

ConflictingTemplateTest

This integration test fails the build if any ViewModel extends classes or implements interfaces that have conflicting @ViewTemplate annotations. These annotations “conflict” if a ViewModel specifies a ViewTemplate to something that does not extend the parent ViewTemplate. For example, LeadCarouselViewModel fails this test:

// The original definition of ListModuleViewModel using List.hbs
public class ListModuleViewModel extends ViewModel<ListModule> implements ListView {}

@ViewTemplate("/core/list/List.hbs")
public interface ListView /* extends a number of Field interfaces */ {}

// Intended to replace ListModuleViewModel's List.hbs with LeadCarousel.hbs
public class LeadCarouselViewModel extends ListModuleViewModel implements LeadCarouselView {}

// LeadCarousel.hbs does not extend List.hbs because LeadCarousel.json does not "_include": "List.hbs"
@ViewTemplate("/core/list/LeadCarousel.hbs")
public interface LeadCarouselView /* does not extend ListView */ {}

In this case, the view system will try to do the right thing and instantiate LeadCarouselViewModel (the “most concrete” viewmodel it can find), but it uses List.hbs as its template. This is neither correct nor incorrect, as this is an invalid configuration.

To exclude a specific ViewModel from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.ConflictingTemplateTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/ConflictingTemplateTest.ignored.txt. Additionally, “ignored” files for the old location of this class (brightspot.sharedtest.ConflictingTemplateTest) are also honored.

ContentLifecycleEmbeddedTest

This integration test flags any implementations of the ContentLifecycle interface which are @Recordable.Embedded Embedded records exhibit inconsistent behavior with ContentLifecycle so it’s best to avoid it entirely for them; instead, put logic from the ContentLifecycle.onNew() method into a nullary constructor.

To exclude a specific ContentLifecycle class from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.ContentLifecycleEmbeddedTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/ContentLifecycleEmbeddedTest.ignored.txt.

Introduced in version 1.4.0.

DuplicateAlterationsTest

This integration test ensures that all type+field+annotation triples and type+annotation pairs in Alterations are unique in the project, taking into account super- and sub-class relationships as well as interfaces/modifications.

If you have multiple Alterations targeting the same annotation, the last one processed will take precedence, overwriting any changes previous Alterations made. Alterations targeting super/sub class pairs suffer from this same ordering problem: there is no logic to e.g. process the Alteration of the superclass first, and then the subclass’ Alteration. Because of this, only a single Alteration should ever apply an annotation to a field or class, though having multiple Alterations apply different annotations to the same field or class is fine.

To exclude a specific Alteration from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.DuplicateAlterationsTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/DuplicateAlterationsTest.ignored.txt.

DuplicateClassFileTest

This integration test ensures that different versions of the same class file do not exist in multiple JAR files included in the project.

This can happen due to failed attempts at “shadowing” classes - that is, intentionally duplicating a platform or third-party class to temporarily fix a bug. This only works if the duplicate class is directly in the WAR file, not in a JAR file. The proper way to shadow a file, then, is to make sure it’s copied into the “site” module, not “core” or any other JAR-producing module.

Another common cause is a failed attempt at “materializing” entire modules. In this case every class in the library should be copied into the “core” module and the dependency should be removed.

Both of these mistakes cause the class loader to nondeterministically select one or the other of the included class files, which can result in errors or unexpected behavior in the application.

If the error generated by this test involves ${project}-core.jar, the remediation is simple:

If the intent is to “shadow” that file, just move the file from the ./core module into the ./site module at the same location.

If the intent is to “materialize” a module, remove the dependency that the JAR corresponds to.

For example, a common component-lib module to materialize is memoization-query-modifiers, but if you neglect to remove the memoization-query-modifiers dependency, you will end up with two copies of brightspot.memoization.MemoizationQueryModifier. So in this case the correct remediation is to remove the dependency.

If the error involves two third-party dependencies, such as org.apache.log4j which is provided by log4j-over-slf4j and log4j, you can add a global exclusion for one of the dependencies. Use ./gradlew ${project}-site:dependencies to determine the group and name of the dependency. Best practices for determining which module to exclude are evaluated on a case by case basis, but in general if the dependency is explicitly listed in the brightspot-dependencies BOM, keep it and remove the other one.

If your project uses Brightspot’s Gradle plugins, you can use its dependency substitution functionality to replace all instances of the duplicate dependency with a specified one.

As always, as a last resort you can exclude certain classes from this test. This is not recommended!

To exclude a specific class from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is The fully qualified class name of this test is brightspot.general.DuplicateClassFileTest, “ignore” filename is ./src/test/resources/brightspot/general/DuplicateClassFileTest.ignored.txt.

JobStatusTest

This unit test ensures all JobStatus implementations have the following required statuses:

• JobStatus.StatusProperty.PENDING
• JobStatus.StatusProperty.PERMANENT_FAILURE
• JobStatus.StatusProperty.SUCCESS

Additionally, if a JobStatus.StatusProperty.RETRY is defined, a JobStatus.StatusProperty.MAX_RETRIES status must also be defined to ensure the job will not retry forever.

To exclude specific JobStatus classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.JobStatusTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/JobStatusTest.ignored.txt.

InternalNameUniquenessTest

This integration test checks all content types to ensure they have unique internal names for all fields and non-ignored methods.

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.InternalNameUniquenessTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/InternalNameUniquenessTest.ignored.txt.

ModificationFieldInternalNamePrefixTest

This unit test checks all Modifications of Object, Record, abstract classes, and interfaces to ensure that either all serializable fields are annotated with an InternalName or the modification class itself is annotated with a FieldInternalNamePrefix.

This test also verifies that if @FieldInternalNamePrefix is present, no fields have @InternalName as those annotations stack, which can result in a redundant prefix.

To exclude specific Modification classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.ModificationFieldInternalNamePrefixTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/ModificationFieldInternalNamePrefixTest.ignored.txt. Additionally, “ignored” files for the old location of this class (brightspot.objecttype.ModificationFieldInternalNamePrefixTest) are also honored.

ModificationInvalidAnnotationTest

This unit test checks all Modifications of Object, Record, abstract classes, and interfaces to ensure that all class level annotations are valid annotations that can be applied to a modification.

This test will only fail if invalid annotations are present, and will not fail for annotations such as @FieldInternalNamePrefix or @Deprecated.

To remediate these annotations, remove them off of the Modification class and apply to the concrete class, or use an Alteration if the class is not accessible on the project or the annotation needs to be applied to an interface.

To exclude specific Modification classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified name is brightspot.sharedtest.ModificationInvalidAnnotationTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/ModificationInvalidAnnotationTest.ignored.txt.

Note: it is not recommended to exclude classes from this test as these annotations will not function correctly when applied to the Modification class.

NoAfterCreateOutsideModificationsTest

This unit test ensures all non-Modification classes do not override afterCreate() from Record as it is only intended for use within a Modification. Instead, either:

• Implement ContentLifecycle’s onNew() method (non-@Embedded content types only)
• Annotate a method with @Relocate (non-@Embedded content types only)
• Create a nullary constructor and put the logic from afterCreate() in that method/constructor

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.NoAfterCreateOutsideModificationsTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/NoAfterCreateOutsideModificationsTest.ignored.txt. Additionally, “ignored” files for the old location of this class (brightspot.objecttype.NoAfterCreateOutsideModificationsTest) are also honored.

NoFinalFieldsInRecordsTest

This unit test ensures Records do not have any non-ignored, non-static final fields, as Dari needs to be able to set values for all instance fields after a Record object is instantiated.

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.NoFinalFieldsInRecordsTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/NoFinalFieldsInRecordsTest.ignored.txt. Additionally, “ignored” files for the old location of this class (brightspot.objecttype.NoFinalFieldsInRecordsTest) are also honored.

NoOverrideEqualsInRecordsTest

This unit test ensures Records do not override the public boolean equals(Object) method from the Record class.

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.NoOverrideEqualsInRecordsTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/NoOverrideEqualsInRecordsTest.ignored.txt.

NoOverrideHashCodeInRecordsTest

This unit test ensures Records do not override the public int hashCode() method from the Record class.

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.NoOverrideHashCodeInRecordsTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/NoOverrideHashCodeInRecordsTest.ignored.txt.

NoShadowedClassesTest

“Shadowed” classes are classes that are directly in the WAR file, rather than in a JAR file within the WAR file. They are loaded preferentially before classes within JAR files so they effectively shadow any corresponding classes that are in a JAR file. Classes can be deliberately shadowed (typically as a quick fix or for testing a potential fix) or they can be unintentional (as a naming conflict, for example).

Most cases of deliberate shadowing are better solved via Substitution which is a more fine-grained way to achieve most of the same ends as a shadow. Because of this, shadowing classes is disallowed by this test.

Note that DuplicateClassFileTest also catches duplicate classes within the build but specifically looks at all the classes in JAR files only. It ignores shadowed classes.

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.NoShadowedClassesTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/NoShadowedClassesTest.ignored.txt.

Introduced in version 1.0.0.

ObjectTypeAnnotationValidationTest

This integration test validates various annotations which specify field and method names, ensuring they actually exist and, when appropriate, that they are of the expected type.

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.ObjectTypeAnnotationValidationTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/ObjectTypeAnnotationValidationTest.ignored.txt.

Introduced in version 1.2.0.

PageViewsNotIncludedInOtherViewsTest

This integration test fails the build if any Views implemented by PageEntryView ViewModels are themselves included as the field type for a View. For example, this setup would fail the test:

ArticlePage.json
{
  "_template": "ArticlePage.hbs",
  "_wrapper": false
}

Page.json
{
  "_template": "Page.hbs",
  "_wrapper": false
  "below": {
    "_include": "ArticlePage.json"
  }
}

public interface ArticlePageView extends PageViewBelowField { }

public class ArticlePageViewModel extends ViewModel<Article> implements
        ArticlePageView,
        PageEntryView {
}

When page-level Views are included in other Views it can result in circular includes in the styleguide build. Even if the styleguide builds, this is generally a sign of improper modeling in styleguide. To resolve this, Views which include the page-level View should instead include a separate View, e.g. Promo rather than ArticlePage. Creating a new View may also be warranted. An example fix for the above scenario would be:

ArticlePage.json
{
  "_template": "ArticlePage.hbs",
  "_wrapper": false
}

Page.json
{
  "_template": "Page.hbs",
  "_wrapper": false,
  "below": {
    "_include": "Promo.json"
  }
}

You may find that this test fails because your PageEntryView ViewModel unexpectedly implements com.psddev.styleguide.PreviewPageViewMainField. In this case, you likely did not set the “_wrapper” key to be false in that view’s JSON, as shown in the examples above.

To exclude specific ViewModel or View Interface classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.PageViewsNotIncludedInOtherViewsTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/PageViewsNotIncludedInOtherViewsTest.ignored.txt. Additionally, “ignored” files for the old location of this class (brightspot.viewmodel.PageViewsNotIncludedInOtherViewsTest) are also honored.

RecordableCollectionGetterTest

This integration test ensures all getters for List, Map, and Set fields of Recordable classes return non-null values that are linked to the actual field.

Your getters should look something like this:

public List<String> getValues() {
    if (values == null) {
        values = new ArrayList<>();
    }
    return values;
}

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.RecordableCollectionGetterTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/RecordableCollectionGetterTest.ignored.txt.

Introduced in version 1.1.0.

RecordableHasNullaryConstructorTest

This unit test ensures all Record implementations have a nullary constructor as Dari requires one to insantiate instances of each Record type.

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.RecordableHasNullaryConstructorTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/RecordableHasNullaryConstructorTest.ignored.txt.

RichTextElementPreviewTest

RichTextElements must have either RichTextElement.Tag#preview() == true and have overridden RichTextElement#writePreviewHtml() OR RichTextElement.Tag#preview(} == false and not have overridden RichTextElement#writePreviewHtml().

If you already have RichTextElement.Tag#preview() == true you will probably want to implement the method rather than switch that to false as doing so will impact how that RichTextElement displays in the rich text field (it will no longer be full width with a gray background).

To exclude specific RichTextElement classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.RichTextElementPreviewTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/RichTextPreviewTest.ignored.txt.

RichTextElementUniqueTagTest

This integration test ensures each RichTextElement has a unique tag value.

To exclude specific RichTextElement classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.RichTextElementUniqueTagTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/RichTextElementUniqueTagTest.ignored.txt.

RichTextElementUnitTest

This unit test ensures each RichTextElement has a @RichTextElement.Tag annotation with a non-blank tag value.

To exclude specific RichTextElement classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.RichTextElementUnitTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/RichTextElementUnitTest.ignored.txt.

SubstitutionUnitTest

This unit test ensures Substitution implementations are valid.

• Substitutions must be a concrete class. If you need to target an interface, use the @SubstitutionTarget annotation.
• Substitutions cannot target another Substitution; target what that Substitution targets instead. If you’re trying to change an existing Substitution, either change it directly if you have acccess to it, or remove the dependency it’s part of from your project so you can write your own Substitution within your project.
• Substitutions cannot have constructors as they will not be substituted onto the target class.
• Only public static fields are supported. Use Modification to add instance fields to the target class.
• You cannot reduce method visibility via Substitution, nor can you change a static method to an instance method or vice versa.

The “target” of a Substitution is the class that will be substituted into. It is either the class specified in the @SubstitutionTarget annotation on the Substitution class, or the superclass of the Substitution class.

To exclude specific Substitution classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.SubstitutionUnitTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/SubstitutionUnitTest.ignored.txt.

Introduced in version 1.3.0.

SuggestibleTest

This integration test ensures all Suggestible implementations specify valid fields in their getSuggestibleFields() methods.

To exclude specific Suggestible classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.SuggestibleTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/SuggestibleTest.ignored.txt.

Introduced in version 1.2.0.

ThemeCompatibilityTest

This unit test ensures a theme is compatible with the root styleguide.

The mechanism for doing so is simply running Styleguide Codegen against each theme and comparing the generated view class definitions against those generated for the root styleguide.

See: Example Theme Compatibility Test Failures for details on common test failures and what to do about them.

Special configuration is not necessary, but the following options are available:

bundle {
    // mode for ThemeCompatibilityTest
    // defaults to 'error'
    // will be set as the theme.*.compatibilityTestMode build system property
    testMode = 'warn'  // 'disable', 'error', or 'warn'

    // for excluding specific JSON files from ThemeCompatibilityTest
    // paths are relative to the root of the generated zip
    // will be set as the theme.*.compatibilityExcludedPaths build system property
    compatibilityTestExcludedPaths = [
        '_files.json',
        'path/to/some/ignored/file.json'
    ]
}

Legacy configuration

Like CdnCssTest, themes are defined with properties like theme.${themeName}.buildDir. These are set for you automatically using express-site.gradle plugin version 1.0.19 or higher.

The default behavior is to print a warning when incompatibilities are detected but not fail the build. In order to fail the build, add the test section below to site/build.gradle.

It is also necessary to add com.psddev:styleguide-codegen as a testImplementation dependency. This is done for you if you’re using brightspot-gradle-plugins v4.1.12 or newer.

site/build.gradle:

dependencies {
  testImplementation 'com.psddev:styleguide-codegen'
}

test {
    project.rootProject.allprojects.each {
        if (it.name.contains('-theme-')) {
            systemProperties.put('theme.' + it.name + '.compatibilityTestMode', 'error')
        }
    }
}

Alternatively, in order to set the test mode for individual themes:

test {
    systemProperties.put('theme.my-theme.compatibilityTestMode', 'error')
}

Valid values for compatibilityTestMode are error, warn, and disable.

Exclusions are not recommended, but if they are absolutely necessary you can create another system property called theme.${themeName}.compatibilityExcludedPaths with a comma-separated list of excluded paths. For example, in site/build.gradle:

test {
    systemProperties.put('theme.my-theme.compatibilityExcludedPaths', 'examples,core/video')
}

ValidIndexedMethodsTest

This integration test ensures @Indexed methods on Recordable types are valid “Object Method Capable” methods. Namely,

• the method must be public,
• the method’s name must start with get, is, or has,
• the method must not be static,
• the method must have a return type that is a valid object field (see ValidObjectFieldTypesTest below),
• the method must either have no parameters or have a single ObjectMethod parameter.

Adding the @Indexed annotation to a method that does not meet these requirements will not create an entry in the Symbol table, and attempting to query with the index will result in a silent failure!

This test fails if it detects any such methods.

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.ValidIndexedMethodsTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/ValidIndexedMethodsTest.ignored.txt. Additionally, “ignored” files for the old location of this class (brightspot.objecttype.ValidIndexedMethodsTest) are also honored.

ValidNonIndexedMethodsTest

This integration test ensures non-indexed @Ignored(false) methods on Recordable types are valid “Object Method Capable” methods. Namely,

• the method must be public,
• the method’s name must start with get, is, or has,
• the method must not be static,
• the method must have a return type that is a valid object field (see ValidObjectFieldTypesTest below),
• the method must either have no parameters or have a single ObjectMethod parameter.

Adding the @Ignored(false) annotation to a method that does not meet these requirements will not create an ObjectMethod for it and it will be ignored, potentially without any errors logged.

This test fails if it detects any such methods.

See also ValidIndexedMethodsTest, above, which tests @Indexed methods for the same conditions; this test does not cover them.

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.ValidNonIndexedMethodsTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/ValidNonIndexedMethodsTest.ignored.txt.

Introduced in version 1.1.0.

ValidObjectFieldTypesTest

This integration test ensures fields on Recordable types are a valid Dari primitive type or another Record. Attempting to use types that do not meet this requirement result in a runtime warning: Can't use [class java.util.SomeClass] for [someField] in [com.some.record.Class].

This test fails if any such fields are detected.

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.sharedtest.ValidObjectFieldTypesTest, “ignored” filename is ./src/test/resources/brightspot/sharedtest/ValidObjectFieldTypesTest.ignored.txt. Additionally, “ignored” files for the old location of this class (brightspot.objecttype.ValidObjectFieldTypesTest) are also honored.

Deprecated tests

AlterationClassAnnotationProcessorTest

Alteration can be used to add annotations to an existing model class. The annotations added must have an associated ObjectType.AnnotationProcessorClass to be compatible with Alteration.

To exclude specific Alteration classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.objecttype.AlterationClassAnnotationProcessorTest, “ignored” filename is ./src/test/resources/brightspot/objecttype/AlterationClassAnnotationProcessorTest.ignored.txt.

AlterationUnitTest replaces this test.

AlterationFieldAnnotationProcessorTest

Alteration can be used to add annotations to the fields of an existing model class. The annotations added must have an associated ObjectField.AnnotationProcessorClass to be compatible with Alteration.

To exclude specific Alteration classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.objecttype.AlterationFieldAnnotationProcessorTest, “ignored” filename is ./src/test/resources/brightspot/objecttype/AlterationFieldAnnotationProcessorTest.ignored.txt.

AlterationUnitTest replaces this test.

AlterationFieldsExistTest

Adding fields to an Alteration that do not already exist in the target class has no effect, and it is likely that the intent was to create a Modification instead.

To exclude specific Alteration classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.objecttype.AlterationFieldsExistTest, “ignored” filename is ./src/test/resources/brightspot/objecttype/AlterationFieldsExistTest.ignored.txt.

AlterationIntegrationTest replaces this test.

EnhancementViewModelTest

This test fails the build if any RichTextElements do not have ViewModels implementing EnhancementViewItemField.

To exclude specific RichTextElement classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.enhancement.EnhancementViewModelTest, “ignored” filename is ./src/test/resources/brightspot/enhancement/EnhancementViewModelTest.ignored.txt.

NoAbstractSubstitutionTest

This test fails the build if any Substitutions extend abstract classes. This is invalid, but it is only possible to catch at runtime.

To exclude specific Substitution or Model classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.objecttype.NoAbstractSubstitutionTest, “ignored” filename is ./src/test/resources/brightspot/objecttype/NoAbstractSubstitutionTest.ignored.txt.

NoAlterationMethodsTest

Methods on an Alteration class will be completely ignored, and it is likely that the intent was to create either a Modification or Substitution instead.

To exclude specific Alteration classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.objecttype.NoAlterationMethodsTest, “ignored” filename is ./src/test/resources/brightspot/objecttype/NoAlterationMethodsExistTest.ignored.txt.

AlterationUnitTest replaces this test.

NoSubstitutionInterfacesTest

Implementing an interface with a Substitution has no effect, and it is likely that the intent was to create an Augmentation instead.

To exclude specific Substitution classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.objecttype.NoSubstitutionInterfacesTest, “ignored” filename is ./src/test/resources/brightspot/objecttype/NoSubstitutionInterfacesTest.ignored.txt.

SearchableLinkableTest

Linkables are often queried from Solr (e.g. in the CMS) which can cause exceptions if there are models implementing Linkable which are not also in the Searchable group.

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.objecttype.SearchableLinkableTest, “ignored” filename is ./src/test/resources/brightspot/objecttype/SearchableLinkableTest.ignored.txt.

SearchablePromotableTest

Promotables are often queried from Solr (e.g. in DynamicItemStream) which can cause exceptions if there are models implementing Promotable which are not also in the Searchable group.

To exclude specific Recordable classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.objecttype.SearchablePromotableTest, “ignored” filename is ./src/test/resources/brightspot/objecttype/SearchablePromotableTest.ignored.txt.

SingleSubstitutionTest

This test fails the build if any types are substituted with Substitutions (old implementation only) more than once. This is invalid, but it is only possible to catch at runtime.

To exclude specific Substitution or Model classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.objecttype.SingleSubstitutionTest, “ignored” filename is ./src/test/resources/brightspot/objecttype/SingleSubstitutionTest.ignored.txt.

SubstitutionIsRecordTest

This test fails the build if any Substitutions extend classes that do not extend Record. Implementing Substitution on anything other than a Record has no effect, and should simply be removed.

To exclude specific Substitution classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.objecttype.SubstitutionIsRecordTest, “ignored” filename is ./src/test/resources/brightspot/objecttype/SubstitutionIsRecordTest.ignored.txt.

ViewModelAbstractMethodErrorTest

This test validates that all ViewModel implementations in your project have concrete implementations of every method declared in their respective View interfaces. This test can fail if View interfaces defined in another module are redefined in your project styleguide without also extending the corresponding ViewModels in your project.

To exclude specific ViewModels classes from this test, see Ignoring Certain Classes for Dynamic Tests. The fully qualified class name is brightspot.viewmodel.ViewModelAbstractMethodErrorTest, “ignored” filename is ./src/test/resources/brightspot/viewmodel/ViewModelAbstractMethodErrorTest.ignored.txt.