Home
CUTTE -- CommUnity Test Tools Extensions
For the latest version of this documentation, please see https://github.com/CUTTE/CUTTE/wiki
Introduction
A collection of community-built extensions and helpers for use with Unity's excellent Unity Test Tools asset.
The package is built in open-source on Git and periodically packaged-up to the Asset Store for convenience of use (update visibility in Asset Store).
The package currently consists of the IntegrationTestSequence utility and some additional Comparers.
IntegrationTestSequence
IntegrationTestSequence: Introduction
IntegrationTestSequence is a utility to aid integration-testing classes. The use-case is as follows...
You have a custom class that you wish to integration test. You want to test it within a scene and need to invoke methods before testing assertions. Ideally, you would:
-
check pre-conditions
-
invoke a method
-
check post-conditions
Perhaps you also want to pause slightly between some of these steps.
The AssertionComponent provided by Unity in their Test Tools allows integration testing in a nice extensible way. Great as it is, there is not presently a convenient way to order the steps as above (1). Rather than write custom code to perform these steps, IntegrationTestSequence provides a convenient GUI for your use. A full sample scene demonstrating its functionality is included with the package.
1. You can do something more like this with the modified NUnit provided with Unity Test Tools but, as the name suggests, it's more focused on unit testing so large assemblies such as those found in a scene are rather cumbersome -- better suited to its Integration Testing aspect.

IntegrationTestSequence: Testing a class
A full sample scene is included -- see this for clarifications.
-
Create the integration test structure you wish to use as usual with Unity Test Tools. A brief summary follows (but see Unity Test Tools documentation for full details):
a. Unity Test Tools | Integration Test Runner
b. Hit the "+" icon to "create new test", repeating and arranging into a hierarchy
c. Under each test, create appropriate GameObjects and Components needed for your test.
d. Create AssertionComponent(s) to test conditions that are affected by your method calls.
-
For the AssertionComponents that you wish to be activated between or after your method calls:
a.
Set Disabled (they will be enabled by EnableAssertion steps we'll add shortly)b. Deselect "Start" (by clicking "Start" and selecting "Nothing")
c. Select "On Enable".
-
Add an IntegrationTestSequence Component to your test
-
Set its Default Target to the class you want to call methods upon.
-
Add and configure steps of appropriate types (summary here, full details further below):
a.
Method Call: Invokes a methodb. Delay: Delays for a number of seconds (including fractional)
c. Enable Assertion: Enables a disabled AssertionComponent
d. Show Message: Prints a Debug.Log() message to the console.
e. Done: Completes the integration test (fires IntegrationTest.Pass() -- see below)
-
Done! Run your test!
Details for some of the specific steps follows...
IntegrationTestSequence: StepType.MethodCall
This invokes a method by name on the default target or an override target if one is supplied. An optional argument can be supplied (currently a GameObject or string).
IntegrationTestSequence: StepType.EnableAssertion
This enables a previously disabled AssertionComponent which, if configured to activate "On Enabled", will promptly test is assertions.
IntegrationTestSequence: Other notes
Do not use "Succeed on assertions"
It ignores AssertionComponents that are disabled at test start which is required for IntegrationTestSequence to enable any assertions. Instead, indicate completion using the "Done" step (which fires IntegrationTest.Pass()).
Duplicating can cause bad references
When duplicating IntegrationTestSequence Components (or GameObjects including an IntegrationTestSequence Component), sometimes the references can get messed up. (e.g. IntegrationTestSequence has a reference to a defaultTarget to send the method calls to. This can point to the original target rather than the newly duplicated one.) If tests start behaving oddly, this might be the cause. To check, click each reference and ensure the expected GameObject is highlighted (yellow). (I tend to do this anyway for safety after duplicating a test.)
Some references have colour highlighting to indicate when there's a potential problem. When seen, the label of the offending reference has a tooltip explaining the problem. They colour red for definite problem and magenta for a potential problem.
Comparers
MaterialComparer
Compares materials for equality or inequality.
FloatDirectionComparer
FloatDirectionComparer asserts a float variable always moves in a defined direction (up/down) with optional leeway (number of frames it is allowed to not go that direction).
Contributing
TODO:
-
Contributor agreement (per http://opensource.org/faq#contributor-agreements include "change license" option in case Unity wish... .)
-
Currently tracked in Trello board. In future, perhaps...
-
GitHub Issues?
-
Wiki (future?)
-
Changelog
2014/07/05 - Version 0.3
Initial open-source publication as CUTTE -- CommUnity Test Tools Extensions (from Unreasonably Good Unity Test Tools).
2014/06/29 - Version 0.2
TestSteps re-written for maintainability and extensibility (individual test steps classes rather than single class with all data and code). Renamed to IntegrationTestSequence.
2014/05/28 - Version 0.1
Project originally mooted by +Rupert Key | @Arakade in the Unity Test Tools Forum thread.
License
BSD 3-clause license (from advice in http://wiki.civiccommons.org/Choosing_a_License )
A Contributor agreement is needed to accept contributions (see http://wiki.civiccommons.org/Contributor_Agreements )
New files should include header line:
Copyright (c) 2014, Unreasonably Good Software, ltd. BSD license, see Assets/CUTTE/LICENSE.txt