If your code does anything more elaborate than adding stand-alone closures, consider having your script explicitly define a class and then instantiate it. This provides a “fence” to protect us against certain types of errors, such as mistyping a field name and ending up adding something to the binding instead. All built-in Groovy rules provided by abuild follow this convention.

When writing custom rules or defining additional targets, allow all defaults to be overridable through parameter settings. This helps to avoid locking the user into a set of conventions. Abuild's Groovy backend's runActions method provides an easy framework that enables your rules to offer the same layers of customization that are provided by abuild's own rules. For an example of using this construct, see Section 22.3, “Code Generator Example for Groovy”.

When developing support for a new test framework, you only have to add new closures for the test-only target. Abuild automatically calls the test-only from both test and check. This is actually different in the make backend, which requires adding code to all three test-related targets. The reason we don't have to do this in Groovy is that our target framework allows to explicitly call one target from another in a dependency-aware fashion.

Instead of adding closures to test-only, you may instead decide to create your own custom target, make it a dependency of test-only, and add your closures to your custom target. This is what both QTest and JUnit support do. The advantage of this approach is that it makes it possible for you invoke a particular collection of tests explicitly and, for build items that use more than one test framework, prevents later tests from being skipped if earlier ones fail.