Identifying modules' characteristics

When navigating to a module's details in the Forge, you are presented with its README file. An empty or very sparse documentation speaks of little care taken by the module author. A sample manifest in the README file is often a good starting point in order to put a module to work quickly.

If you are looking for a module that will enhance your agents through additional resource types and providers, look for the Types tab on the module details page. It can also be enlightening to click on the Project URL link near the top of the module description. This usually leads to GitHub. Here, you can conveniently browse not only the plugins in the lib/ subtree, but also get a feel of how the module's manifests are structured.

Another sign of a carefully maintained module are unit tests. These are found in the spec/ subtree. This tree does exist for most of the Forge modules. It tends to be devoid of actual tests, though. There can be test code files for all the classes and the defined types that are part of the module's manifest - these are typically in the spec/classes/ and spec/defines/ subdirectories, respectively. For plugins, there will ideally be unit tests in spec/unit/ and spec/functions/.

Some README files of the modules contain a small greenish tag saying Build passing. This can turn red on occasions, stating Build failing. These modules use the Travis CI through GitHub, so they are likely to have at least a few unit tests.