Introduction Quick Start Guide UnityScript or C# Tests in external ...

sandpaperleadΛογισμικό & κατασκευή λογ/κού

31 Οκτ 2013 (πριν από 4 χρόνια και 7 μέρες)

85 εμφανίσεις

uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

1

Introduction

uUnit allows Unity3d developers to utilise Test driven development

(TDD)

methodologies
. TDD has been embraced
by all areas
of development
and
across almost all
industries
,
and enables developers to produce well written code
that works first time.

Written to closely resemble

nUnit
,

the extremely popular .net unit testing
framework,
uUnit uses as many of the
same
naming conventions as it can
. If you are familiar with nUnit the
n using uUnit should be straightforward and
simple.

uUnit has been written to solve
a unique Unity3d problem: the existing testing frameworks don’t work with
Unity3d
’s state model. Also, no unit testing frameworks exist for UnityScript.

It is advised that if you are new to TDD you do some research on how to structure your code


it
will make your
development process considerably more pleasant.

Quick Start Guide

For those whom reading documentation is a chore or those who are familiar with

unit testing
frameworks,

here is
the minimum you need to know to get unit tests working in your Unity Game.

1.

Import uUnit assets

2.

Create new scene for unit testing

3.

Create new script extending from
TestManagerBase
.


4.

Drag

the

script onto the default Camera in the scene.

5.

Create new script containing unit tests

6.

Run
your
Unit test scene in editor


the

u
nit tests will be run

automatically
.

UnityScript or C#

uUnit

supports both UnityScript and C#, neither is more difficult to write unit tests for, but there are some subtle
differences in the code you write.

This document has c#
code
examples.
To translate a C# uUnit
test
script to a UnityScript one, apply the foll
owing
translations:

Action

C#

UnityScript

Apply attribute

[TestFixture]

@uUnit.TestFixture

Use Assertions

Assert.AreEqual(…)

uUnit.Assert.AreEqual(…)


TU牯ugUou琠WU楳iTocumen琠楴⁨a猠b敥n⁡獳umeT⁴Ua琠uUn楴⁨a猠b敥n⁡TTeT⁴o⁥慣U
C
⌠獣物pW⁢礠
sp散楦eing
:


using

uUnit;

Tests in external assemblies

Good design practices suggest you separate your code from your unit tests.
This enables you to ensure that you do
not ship test code with your final product.

To enable you to do this easily,
uUnit supports load
ing external
assemblies containing uUnit tests into your project.

uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

2

To enable running tests from external assemblies the
TestSceneManager
.

TestAssembly

property must be
overridden to return the assemblies to be examined for tests.

To continue to run tests
from the local project, combine the output from the base class with your own assemblies.

protected

override

Assembly
[] TestAssembly

{


get


{


var

customTestAssemblies =
new

List
<
Assembly
>();



// Load external assemblies


customTestAssemblies.Add(
Assembly
.Load(
"ExternalUnitTests1"
));


customTestAssemblies.Add(
Assembly
.Load(
"ExternalUnitTests2"
));



// Include the standard classes (tests written within the Assembly
-
UnityScript


// & Assembly
-
CSharp proje
cts)


customTestAssemblies.AddRange(
base
.TestAssembly);



return

customTestAssemblies.ToArray();


}

}

Command Line Options

uUnit offers command line options similar to that
of nUnit.
These allow you to automate uUnit actions within
your
Game
.


Command

Description

RunTests

Tests should be run in preference to
normal game code.


myGame.exe /RunTests


Note: Requires uUnit code in first scene to register command line arguments.

ExitAfterTests

The game should exit after all tests have finished running.


myGame.exe /ExitAfterTests


Designed to be used in
conjunction with /RunTests to enable Continuous
Integration builds to run unit tests the
n

exit.

Work

The directory that test results xml should be written.


myGame.exe /
Work
:C:
\
GameTests
\


If not specified,
uUnit

uses
the current working directory
(usually the directory
where the Game executable is located).

Output

The filename that the test results xml will be written to.


myGame.exe /Output:UnitTestResults.xml


If not specified, then the filename is defaulted to TestResult.xml.


Command line
options can be combined in any order to create the desired action.

Examples:

uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

3

Run unit tests and output results to a file named Tests.xml in the current directory

<executable> /RunTests /Output:Tests.xml

Run unit tests and output results to TestResult.xml i
n current directory, then close the game.

<executable> /RunTests /ExitAfterTests


Execute game, if unit tests are run manually, output the results to C:
\
Output.xml

<executable> /Work:C:
\

/Output:Output.xml

Unit test types

uUnit

supports two distinct type of unit tests, Blocking and Yielding.

Blocking Tests

A blocking test is one that once started will not allow any other code to run until it has finished.

This is likely to be
the most often written type of unit test and very closely resembles unit tests you might write in nUnit (or other .net
unit testing frameworks).

Blocking tests have the
[Test]

attribute applied to a
public void

method which takes zer
o or more parameters.

Blocking tests that have input parameters are only valid when those parameters are decorated with
method
parameter attributes (for example
[Range]

or
[Values]
)


Blocking tests may cause the test GUI to ‘Hang’ if they take a very long time to execute.

TU楳⁩猠norm慬a
beUav楯ur⁡湤⁷楬氠

晬散f

wU慴am慹⁨慰p敮⁩e⁧慭e.

TU攠䝕䤠I楬氠捯n瑩nue⁷or歩kg⁡ norm慬⁷Uen⁴U攠
瑥獴s捯mp汥瑥s.


T特r瑯⁡voiT⁷物瑩rg 捯T攠WU慴a瑡W敳e愠aong⁴ime⁴o
ex散畴e
. You can use the ‘Duration’ column on the uUnit
䝕I⁴o
iTen瑩Wy⁴敳e猠瑨慴⁴a步⁡ long⁴ime⁴o⁲un
慳a瑨W獥s
捡n⁩nT楣慴e

獬ow
g慭攠
捯Te.



Yielding Tests

A yielding test is one that runs as a special co
-
routine.

These tests can have
yield

return

calls within them which
will allow unity to continue running (as it would in a game).

Yielding tests are useful when you are testing something that relies on a number of frames, or a passage of time
before they can complete.

Yielding tests have the
[Test]

attribute applied to a
public IEnumerator
method which takes zero or more
parameters.

Like a blocking test, a yielding test that has input parameters are only valid when those parameters are
decorated with method parameter attributes (for example
[Range]

or
[Values]
)

The standard yielding mechanism is available within the test, so using
yield

return

new

WaitForSeconds(10);

would cause the test to wait 10 seconds before running
code after the yield command.

Yielding and returning null will only wait until the next frame render.

uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

4


Yield can only be used within tests.


Setup, Teardown and other methods run either side of a test are always run as blocking and cannot
contain the yield keyword.



uUnit GUI

For interactive execution of unit tests, uUnit provides an interface based on Native unity GUI calls (no additional GUI
frameworks are required).

1.

Test summary, detailing
the overall result of the test run.

2.

List headers, sort direction indicated with arrow
, click to sort by column.

3.

Unit test List
, all
discovered tests in game.

4.

Selected Unit test

5.

Selected test output
, Captured log output displayed as it appears in the debug log window.


T
he results table

can be sorted

during
execution

by clicking on
the
header of the column.

To reverse, or remove the
sort order
,

click again on the header.


The results list will be sorted dynamically during a test run, meaning the order may appear to jump around until all
the results are obtained.

uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

5

Currently sorting
multiple columns is not supported.

Test Result
Output

uUnit supports outputting a

nUnit
2.6
compatible xml file containing the results of the test run. Using the command
line options you can specify where this file is written and its name, or if
run
in the Unity Editor

the
xml
file will be
written to the working directory (usually where YourGame.exe is located) named
TestResult
.xml
.

The results file

can be parsed and integrate
d

with many popular Continuous Integration servers
such as TeamCity or
Hudson/Jenkins
.

The xsd file for the ou
t
put can be found at
http://www.nunit.org/docs/2.6/files/Results.xsd

When running within the Unity Editor, tests results a
re always written to TestResult
.xml in the working directory.
When run from the command line
, uUnit

will
only write xml results if
the
RunTests

or
Outpu
t

command line options
have been specified.

Test Duration

The duration value that is
provided for

a test is
a
rough guide
of

how long a test took to run.
Test
Setup and Tear
down methods are not
included in the figure.


Ordering the completed test run by
duration can help identify which areas of game code are slow to run and may
yield the best frame

rate improvements.

Test Attributes & Methods

The attributes used by uUnit are a subset of those supported by the popular nUnit framework. Their meanings and
u
sage examples are provided below.

Attribute

Valid on


TestFixture

Public
Classes

Denotes a class as having zero or more tests that should be considered for running.


Absence of this attribute will mean the class contents will not be considered as tests

or fixtures
.


Inner public classes that also have this attribute will be considered for running.


Static classes cannot be test fixtures.

namespace

myTests {


[
TestFixture
]


public

class

TestClass

{


// This class will be inspected for tests


}




public

class

NoTests

{


// This class will not be inspected for tests


}




[
TestFixture
]


private

class

NoTestsPrivate

{


// This class will not be
inspected for tests


}

uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

6

}



Attribute

Valid on


Test

Public
instance
Methods

Denotes a method as being a unit test that should
(subject to other attributes) be
executed.

[
Test
]

public

void

AValidBlockingTest(){


// Test content

}


[
Test
]

public

IEnumerator

AValidYieldingTest(){


// Test content

}



[
Test
]

private

void

NotATest_IsNotPublic(){


// This is not a test as the method is not public

}


[
Test
]

public

string

NotATest_ReturnTypeIsNotVoid(){


// This is not a test as the method return type is not void.

}


[
Test
]

public

void

NotATest_HasParameters(
string

parameterOne,
bool

parameterTwo){


// This is not a test as the method requires parameters that are not attributed.

}


Attribute

Valid on


SetUp

Public
parameterless
Methods

Specifies a method to be run before each test.


Often used to perform repetitive setup tasks on a per test basis.


No test context is available to this method so setup should be test agnostic.


Often paired with the [TearDown] attribute.


Me
thods in base classes with the SetUp attribute will be execut
ed before any in
derived classes.


Only one method per fixture may be decorated with this attribute.

[
SetUp
]

public

void

TestSetup(){


// Perform per test setup here.


}




uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

7

Attribute

Valid on


TearDown

Public
parameterless
Methods

Specifies a method to be run after each test.


Often used to perform repetitive tidy up tasks on a per test basis.


No test context is available to this method so teardown should be test agnostic.


Often paired with the [SetUp] attribute.


Guaranteed to run
for all non
-
aborted tests
.


TearDown is not included in test duration calcula
tions.


[
TearDown
]

public

void

TestTearDown(){


// Perform per test tear down here.


}


Attribute

Valid on


TestFixtureSetUp

Public
void
parameterless
Methods

Specifies a method to
be run once before any tests in a [TestFixture] class.


Often used to perform setup tasks that are required by the fixtures tests. For
example creating a test database instance.


Guaranteed to run once only per fixture.

Will run only if Fixture contains o
ne or
more tests.


Often paired with the [TestFixtureTearDown] attribute.


TestFixtureSetUp is not included in test
duration calculations.


namespace

myTests {



[
TestFixture
]


public

class

TestClass

{



[
TestFixtureSetUp
]


public

void

FixtureSetup(){


// Called

once, before any [Setup] or [Test] methods are run.


}






}


}




uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

8

Attribute

Valid on


TestFixtureTearDown

Public
parameterless
Methods

Specifies a method to be run once after all runnable tests in a [TestFixture]
class have
been run
.


Often used to perform tidy up tasks that are required by the fixtures tests.
For example
removing a

test database instance.


Guarante
ed to run
only
once
per fixture
.

W
ill be executed when
all

tests in
fixtures have been executed
.


Often paired with the [TestFixtureSetUp] attribute.


TestFixtureTearDown is not included in test duration calculations.


namespace

myTests {



[
TestFixture
]


public

class

TestClass

{



[
TestFixtureTearDown
]


public

void

FixtureTearDown(){


// Called once, after all [Test] and [TearDown] methods have run.


}






}


}


Attribute

Valid on


Ignore

Test methods
,
TestFixtures

When applied to a Test method,
s
pecifies that
the
t
est method

will not be
executed
.

When applied to a TestFixture, specifies that all test methods in
this fixture and all derived fixtures, will not be executed.


Used to temporarily disable a test, without the need to comment it out.


Ignored tests do not affect the overall success or failure of a run.


Ignored tests do not have Setup or Teardown methods run.

namespace

myTests {



[
TestFixture
]


public

class

TestClass

{



[
Test
,
Ignore
]


public

void

AValidTestThatIsIgnored(){


// This
test is valid, but will not be executed.


}



[
Test
,
Ignore
(
"A reason for the ignored test"
)]


public

void

AnotherIgnoredTest(){


// This test will output the text above to the test console.


}


}

}


uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

9

Attribute

Valid on


ExpectedException

Test methods

Specifies that a test method should throw an exception for it to be
considered to have passed.


Exceptions derived from the expected are not considered
as

equal and will
result in a test fail.


The message of the exception will be compared if the
ExpectedException
Message parameter is specified in the attribute.


namespace

myTests {



[
TestFixture
]


public

class

TestClass

{



[
ExpectedException
(
typeof
(
NullReferenceException
),



FailMessage =

"A null reference exception should have been thrown."
)]


public

void

TestShouldThrowException(){


// Some method call that should throw an exception.


}





[
ExpectedException
(
typeof
(
ArgumentException
),


ExpectedExceptionMessage

=

"Filename parameter was not supplied"
,


FailMessage =
"An argument exception should have been thrown for Filename"
)]


public

void

TestShouldThrowExcepti
onMatchMessage(){


// Some method call that should th
r
ow an exception


}


}


}


Attribute

Valid on


TestTidyUp

TestFixture
s
,
Test methods

Specifies that the state of the ‘Game World’ should be returned (as best as
捡c b攠慣U楥veT) b慣欠瑯⁴U攠獴慴攠楴⁷慳⁩a b敦o牥r瑨攠瑥獴s⡯r⁦楸 u牥⤠w慳a
牵n.


TU楳⁡瑴物buW攠楳ip慲瑩cu污l汹⁵s敦u氠楦lyou⁡ 攠捲敡eing⁧慭eob橥j瑳Ww楴U楮
you爠瑥獴⁷U楣U may⁡晦 捴c瑨攠潵瑣潭攠o映fnoWU敲e瑥獴s


D敦eu汴lv慬ue
楦⁡i瑲Wbu瑥⁩  琠spe
捩晩eT):†剥獴o牥⁴o p牥
-
W敳e

獴慴e


佰瑩on猺



NoTidyUp
-

No tidy up is performed



ToPreTestState


䍬敡湳eup⁡湹 ob橥jW猠sr敡eeT by⁡ 瑥獴



ToPreFixtureState


䍬敡n猠up⁡nybj散es⁣牥r瑥T by⁡⁦楸 u牥



Default
-

ToPreTestState


Fixture level TestTidyUp at
tributes override any test level TestTidyUp
attributes. If your test level settings are not working as expected, it may be
a fixture level setting overriding it!


Limitations:


Only objects created as part of a test or fixture will be removed. The state

of existing objects will remain, so will still reflect changes made to them
uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

10

within the tests or fixtures. Objects destroyed by tests will not be re
-
created.


[
Test
]

[
TestTidyup
(
TidyupType
.NoTidyUp)]

public

void

CreatesLotsOfObjects_TheyShouldNOTBeTidiedUpByuUnit()

{


// Arrange


var

createdList =
new

List
<
string
>();



for

(
var

i = 0; i < 100; i++)


{


var

prim =
GameObject
.CreatePrimitive(
PrimitiveType
.Cylinder);


prim.name =
string
.Form
at(
"NoTestObjectTidyup
{0}
"
, i);


createdList.Add(
string
.Format(
"TestObject
{0}
"
, i));


}



// Act


foreach

(
var

name
in

createdList)


{


var

found =
GameObject
.Find(name);


Assert
.IsNotNull(found,
string
.Format(
"Didn't find object
{0}
"
, name));


}



// Assert

}


Attribute

Valid on


Values

Method
Parameters

Specifies that a test should be executed with each of the values

specified.


Any parameters of a test method must have the [Values], [Range] or
[Random]

applied.


The [Values] attribute can be used interchangeably with the [Random] or
[
Range
] attribute.


A Cartesian of all
the
method parameters

will be used to calculate
all
the
permeations
tests to be executed.

namespace

myTests {



[
TestFixture
]


public

class

TestClass

{



[
Test
]


public

void

ATestWithValues([
Values
(1,2,3)]
int

numbers


, [
Values
(“
A
”, “
B
”)]
string

letters){


// This test will be run 6 times with the
following values:


// 1, “A”


// 2, “A”


// 3, “A”


// 1, “B”


// 2, “B”


// 3, “B”


}


}

}


uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

11

Attribute

Valid on


Range

Numeric
method
parameters

Specifies that the parameters passed to a test will be from a range of
numbers.


Any parameters of a test method must have the [Values], [Range] or
[Random] applied.


The [Range] attribute can be used interchangeably with

the [Values] or
[Random] attribut
e.


namespace

myTests {



[
TestFixture
]


public

class

TestClass

{



[
Test
]


public

void

ATestWithRange([
Range
(1,5,1)]
int

numbers){


// This test will be run 5 times with the following values:


// 1
,
2
,
3
,
4
,
5


}


}

}


Attribute

Valid on


Random

Numeric
m
ethod
p
arameters

Specifies
that th
e parameters passed to the test will be ‘random’ numbers.


䅮y⁰a牡r整敲猠o映愠瑥獴整UoT mu獴⁨慶攠WUe⁛ 慬a敳崬⁛剡 g敝eo爠
孒慮Tom崠慰p汩敤e


TU攠[
剡nTom

a瑴物bu瑥⁣an be⁵獥T⁩nW敲eUang敡b汹lw楴i⁴Ue⁛ 慬a敳崠o爠
[
剡Rge
崠慴a物bu瑥⸠

namespace

myTests {



[
TestFixture
]


public

class

TestClass

{



[
Test
]


public

void

ATestWithRandom([
Random
(1,5,3)]
int

numbers){


// This test
will be run 3 times with the random values between 1 and 5:


}


}

}


Interacting with
GameObjects

Objects that derive from
GameObject

are not as straight forward to test as standard classes.

You cannot create
them using the
new

keyword
,

rather they must be created using the
GameObject.Create
Primative

method or
the
AddComponent

method on an existing scene object.

uUnit

provides
a
GameObjectHost

object

for hosting MonoBehaviour scripts
. The
GameObjectHost

also
manages the state of the objects created using it after the test.

uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

12

[
Test
]

public

IEnumerator

UsingGameObjectHostInTests()

{


var

scriptInstance

=

GameObjectHost
.HostScript<
MonoBehaviourScript
>();




//

Start()

will

be

called

immediately

on

the

scriptInstance

and

the



//

script

will

start

running

Update()

at

the

next

yield.




yield

return

null
;


//

Update

will

now

have

been

called

on

the

script.




yield

return

null
;


//

Update

will

have

been

called

again

on

the

script.




//

You

can

interact

with

the

script

as

if

it

were

a

normal

class.


Assert
.AreEqual(
"An

expected

value"
,

scriptInstance.APublicProperty);




//

All

scripts

created

on

the

GameObjectHost

are

destroyed

automatically


//

when

the

Test

finishes.

}



Using some Unity functionality in blocking tests can cause strange results.

For example

within a blocking
test the
Time

values

will not advance
.



Most
unity
functionality should work

correctly within yielding test
s

as the
yield

return

statement
allows unity to execute the code as it would during the game.


Assertions

The mainstay of unit tests is the assertion

s passing or failing. uUnit

supports this concept through the static
Assert

and
LogAssert

classes.

The
Assert

static class offers a number of methods that can be used at any point of a unit test (or
corresponding
SetUp
) to check a test assertion.

The
LogAssert

class provides assertion functionality specific to the Unity Debug log
(also known as the console)

should a test require it
.

LogAssert is discussed in more depth later in this document.


Assert.That

Provides generic assertion functionality, allowing th
e developer to specify any condition that evaluates to a Boolean,
to be checked.


Assert.That does not provide tailored assertion messages, and therefore it is advisable to use the more specific
assertion methods where possible.

Assert
.That(() =>
true

==
false
,
"True is not equal to false"
);

Assert
.That(() => result ==
"Expected String"
);

Assert
.That(() => resultCollection.Contains(expectedElement),
"Doesn't contain expected element"
);


Assert.
IsNull
, Assert.Null

Checks that the supplied variable is

null.

Assert
.IsNull(result,
"Message for failure."
);

Assert
.Null(result,
"Message for failure."
);


uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

13

Assert.
IsNotNull
, Assert.NotNull

Checks that the supplied variable is not null.

Assert
.IsNotNull(result,
"Message for failure."
);

Assert
.NotNull(
result,
"Message for failure."
);


Assert.
AreEqua
l

Checks that the two values provided are the same.

Assert
.AreEqual(value1, value2,
"Message for failure."
);


Assert.
Are
Not
Equal

Checks that the two values provided are not the same.

Assert
.AreNotEqual(value1, value2,
"Message for failure."
);


Assert.
Is
InstanceOf
<>, Assert.IsInstanceOf
Type

Checks that the value is the specified type.

Assert
.IsInstanceOf<
Type
>(value1,
"Message for failure."
);

Assert
.IsInstanceOfType(
typeof
(
String
), value1,
"Message for failure."
);


Assert.
Throws

Checks that the code throws the specified exception.

Returns the expected exception as its value.

Assert
.Throws<
NotSupportedException
>(() => subject.SomeFunction(),
"Message for failure."
);

Assert
.Throws<
ArgumentOutOfRangeException
>(() => subject.SomeFunction(),
"Expected exception
message"
,
"Message for failure."
);


Assert.
DoesNot
Throw

Checks that the
code does not throw any exception.

Assert
.DoesNotThrow(()

=>

subject.SomeFunction(),

"Message

for

failure"
);


Assert.
Inconclusive

Exits the test with a
n

Inconclusive result.

Assert
.Inconclusive(
"Message for Detail."
);


Assert.
Fail

Exits the test with a Fail result.

Assert
.Fail(
"Message for Detail."
);


Assert.
Ignore

Exits the
test with an ignore result.

Assert
.Ignore(
"Message for Detail."
);


Assert.
Pass

Exits the test with an pass result.

Assert
.Pass(
"Message for Detail."
);


Unity Debug Log

The Debug Log (sometimes referred to as the ‘Console’) allows developers to output Log, Warning and Error
messages from code. Normally these are displayed to the Unity Editor console. uUnit intercepts these messages on a
per
-
test basis.

Log messages contin
ue to be written to the Console in spite of their interception.

Message interception lifetime

uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

14

On a per test basis, the log is intercepted for Test Setup and Test methods scope only. You can still write Debug
messages during FixtureSetup

and Teardown methods, but you will need to inspect the Unity console to view those
messages.

Programmatic access to the log messages is provided through the static
LogAssert

class, with the
LogMessages

property offering a snapshot of all messages that hav
e been intercepted. Therefore it is possible that subsequent
calls to
LogMessages

may return lists of differing length if other threads continue to write to the Debug log.


LogAssert.LogMessages

Provides access to the raw messages that were captured
from the Debug Log as part of the unit test.

Assert
.AreEqual(5,

LogAssert
.LogMessages.Count,

"Should

be

5

log

messages

(of

any

type)"
);


LogAssert.Contains

Asserts that the Log messages captured for the test contains at least one message that fulfils
the criteria.

LogAssert
.Contains(
LogType
.Error,

"At

least

one

message

of

type

Error

was

expected"
);

LogAssert
.Contains(
"This

is

the

message

text"
,

"No

message

with

expected

text

was

found."
);


LogAssert.
DoesNotContain

Asserts that the Log messages
captured for the test does not contain any message that fulfils the criteria.

LogAssert
.DoesNotContain(
LogType
.Error,

"There

should

be

no

messages

of

type

Error."
);

LogAssert
.DoesNotContain(
"This

is

the

message

text"
,

"A

message

with

expected

text

was

fou
nd.

I
t

should

not

have

existed."
);



Although it is possible to call LogAssert methods from outside Test Setup or Test scope (for example,
within a Fixture Setup, o
r Tear down method), the contents of the
LogMessages

property are not
guaranteed


慮T⁴U敲敦er攠楴⁩i W⁲ commenTeT.





It is recommended that you turn off the option to pause the editor on errors
.




uUnit will capture
error information

from
th
e debug log

and continue running other unit tests if this is
turned off. Otherwise all
errors written to the debug log will pause the execution and require the game to
be un
-
paused.


This setting affects uUnit when running in the editor only. Compiled game
executables

do not have this
setting.



uUnit captures the
Debug
Log output from Game code by utilising the
Application.RegisterCallbackThreaded

functionality. Unity o
nly allows one process to capture
the
Debug log at any one time and so you may experience strange behaviour during tests if you call either
RegisterCallback

or
RegisterCallbackThreaded

within your own code.



uUnit
Documentation


uUnit v
2
.
0
.0.0



P
age

15

Questions, Feedback or Bug reports

Questions
regarding unit testing with uUnit and unity should primarily be directed at the Unity Community Question
and Answer site

-

‘Unity Answers’. Tagging a question with ‘u
U
nit’ will ensure a more swift targeted response

to
your question.

http://answers.unity3d.com/questions/topics/uunit.html

Feature requests or Bug reports are best emailed directly to
unity
-
uunit@codedlogic.com

. If submittin
g a bug
report, please provide

as much relevant information as possible and
we will endeavour to fix the bug as quickly as
we are able.

Disclaimer

u
Unit is provided by Codedlogic

Ltd

(herein known as ‘the developer’) "as is" and "with all faults
"
.

The developer
makes no representations or warranties of any kind concerning the safety, suitability, lack of viruses, inaccuracies,
typographical errors, or other harmful components of
uUnit
. There are inherent dangers in the use of any software,
and you
are solely responsible for determining whether
uUnit is

compatible with your equipment and other software
installed on your equipment. You are also solely responsible for the protection of your equipment and backup of
your data, and
the developer

will not
be liable for any damages you may suffer in connection with using, modifying,
or distributing
uUnit
.

About the Developer

Codedlogic Ltd is a

small

Indie software development company based in London, UK. They passionately
believe that
TDD is the future of
well written software, and
computer
games
can benefit as must as any other software type
.
They are
n
o stranger to eating their own dog

food
, and
use
uUnit on a daily basis as part of their own game
development process.