Abuild's backends define several targets that are available for use from the command line, so you can rely on these targets being defined. [28]
This is the default target. It is used to build all products that are intended for use by the end user or by other build items.
This target ensures that the local build item is built and then runs its automated test suite, if any. For this to do anything, the build item must have a test suite implemented with a test framework that is integrated with abuild or that is made available with a plugin. Abuild is integrated with QTest and, for Java-based build items, also with JUnit. The check target is not automatically run by the default target; it must be requested specifically.
        This target removes any output directories that abuild
        thinks it created.  (Output directories are discussed in Section 5.3, “Output Directories”.)  Well-behaved abuild
        rules, including all the rules that are a standard part of
        abuild, won't create any files or directories outside of
        these locations.  See also the description of the
        --clean-platforms (in Section 13.4, “Control Options”) to learn about
        restricting which platform directories are removed.
       
        This target is provided for building documentation that is
        extracted from source code.  The doc target
        is not automatically run by the default target; it must be
        requested explicitly.  It depends on the
        all target.  There is no internal support
        for document generation in the make
        backend, so this capability must be provided by a plugin.  For
        Groovy/ant builds, there is
        built-in support for javadoc, but it is minimal and will
        likely have to be supplemented for any major documentation
        effort.  A contributed plugins to support doxygen is available
        in abuild-contrib, which is released
        separately from abuild.
       
        This target does nothing other than printing the name and
        platform of each build item in the build set, but using it
        still causes abuild to perform all the same validations it
        would perform if it were going to build something.  The
        no-op target can be used to get a complete
        list of all the items and platforms that would be built if
        building a given build set and will also verify that there are
        no errors in any Abuild.conf files.  Note
        that Abuild.interface files are not read
        when invoking the no-op target.
       
This target is a synonym for check.
This target runs any automated test suites but does not first try to build. In other words, the test-only target does not depend on the all target like the check and test targets do. This can be useful for running a test suite on a build item without first rebuilding it or for running all the test suites on a build tree that you know is up to date because you just built it.
[28] 
       When the Abuild-ant.xml build file is used
       with the deprecated xml-based ant backend, it is up to the
       author of the build file to provide these targets, and all bets
       are off.