This project was created by @kgooble and @elmoeleven during one of Uken's 2016 Hadoukathons
Mooble provides tools to perform static analysis on prefabs and scene files - often unchecked in code review and hard to test without someone running the scene and going through every possible flow. Mooble's goal is to help catch errors ahead of time by checking for common errors in scene and prefab files, and allowing you to customize the static analysis by writing your own rules.
All it takes to get started with Mooble is to drop the Mooble directory into
Assets/Plugins
of your own project. Take a look at the sample project provided
here for an example.
This rule makes sure that GameObjects
do not have two of the same type of
Component
, e.g. no GameObject
has two Text
components, etc.
This rule ensures that no
Behaviour
is set to
inactive. You can exclude certain types from this rule (i.e., allowing them to
be inactive in the scene or prefab) by specifying an Exclusions
array in the
configuration. See [config](# Configuration Options) for more details.
This rule ensures that all script components are not referencing missing scripts. If your object has a component with a missing script reference, something has likely gone wrong!
This rule outputs a warning if you have a
MonoBehaviour
with unassigned public
or SerializeField
fields - i.e. those with null
values. This can be a smell in that your script either has some unused code
in it or it may be that your MonoBehaviour
is overly general.
In order to write your own rule, you need to implement the following classes:
-
A class that implements
Rule<T>
, whereT
is the type of component you'd like to validate (otherwise,T
must beGameObject
). Take a look at theRule
file to see which abstract methods must be implemented. -
A class that implements
IViolation
. This is the type of violation that your rule generates. Take a look at the interface in this repository to see which methods it must implement.
After you have implemented the class, add an entry to moobleconfig.json
for
that class. The class name must be fully namespaced. You must also provide the
assembly name which you can find out by running the following code locally:
using System;
using System.Reflection;
public class FindAssembly : MonoBehaviour {
private void Start() {
// SomeClass is a class in your project
Debug.Log(typeof(SomeClass).Assembly.GetName().Name);
}
}
In most cases it will be "Assembly-CSharp"
.
Add a moobleconfig.json
file to your root project directory. This is the file
that the menu items look for when trying to determine what rules you want to
run over your scenes and prefabs. Take a look at the moobleconfig.json
file
provided in this repository for an example.
Only rules listed in the Rules
list will be run.
The IgnoredSceneRootObjectNames
property at the root level of the moobleconfig.json
file allows you to specify object names at the root level of scenes that should be ignored by Mooble.
This can be useful if you need to ignore certain prefabs that are from, say, 3rd party plugins.
The Exclusions
list is to allow users to provide various types that the
rule in question should not run on. This type name must be qualified
with the full namespace and the assembly it belongs to. For example, if you
don't want to run the NoInactiveBehaviours
rule on Animator
behaviours,
add it to the exclusion list:
"Exclusions": [ "UnityEngine.Animator, UnityEngine" ]
Other common assemblies include:
Assembly-CSharp
for code in your projectAssembly-CSharp-firstpass
for code in your plugins directory
Not all rules accept Exclusions
lists; take a look at the code for the
specific rule to check whether it accepts exclusions.
You can integrate Mooble with your Jenkins build by using the command line tools provided (see CLI.cs). You can run the command line static analysis tools by using Unity's batch mode. Make sure to close any open instances of Unity before you run the following:
/Applications/Unity/Unity.app/Contents/MacOS/Unity -quit -batchmode -projectPath ${WORKSPACE} -executeMethod Mooble.StaticAnalysis.CLI.RunPrefabAnalysis ${MOOBLE_PREFABS}
${WORKSPACE}
is the location of the project that has integrated the Mooble plugin, and ${MOOBLE_PREFABS}
in this case is a space-delimited list of prefabs you want to run the prefab analysis on, e.g Assets/Prefabs/A.prefab Assets/Prefabs/B.prefab Assets/Prefabs/MorePrefabs/C.prefab
.