In this video I'm excited to announce that I'll be working on a brand new project an:
MMORPG where you can do whatever you...
Whoa! What to heck!
Who are you?
I'm you!
You're me?
Yeah!
You from the future.
Well, that must mean you have some sort of important message for me right.
Yeah.
Yeah, I actually do have a message and it's about that project.
It's a total flop.
I knew I shouldn't have done an MMO!
Everyone on Discord told me not to.
Especially apieceoffruit.
No, no it's not that.
MMOs are easy.
Anyone can make one.
The problem is with the code.
It's just too coupled.
Every time I fix one bug ten more sprout up in its place.
And there's no way to guard against future regressions.
Oh no.
It sounds awful.
Well, what do we do to fix it?
To be honest, I've been doing my research and I think the answer is unit tests.
Unit tests?
Man, I don't even know how to set up a project for unit tests.
The documentation online is pretty bad.
Don't worry man.
I've been doing a ton of reading.
I gotcha.
All you have to do to get started is to right-click anywhere in your assets folder.
I'm just going to right-click on The Root.
Expand the create menu and then expand the testing menu on you and click on "Test Assembly
Folder".
This will create a folder in your project that's set up for testing.
But what does that mean "set up for testing"?
Well, if we take a look at what's in this folder we can see that there's a test assembly.
The test assembly is set up for, well, testing.
The key here is this constraint:
UNITY_INCLUDE_TESTS.
As well as these assembly definition references to UnityEngine.TestRunner and UnityEditor.TestRunner.
So at this point, we can navigate back to our test folder.
Right click.
Select "create", Expand the testing folder and click on "C# Test Script".
This is just one way to create tests and we're actually not finished.
To show you what I mean, let's open up the test runner which will give us a little more
information.
First, expand the window menu, then general, and click on "test runner".
Here we can see a simple window that has two tabs at the top.
We're currently in the edit mode tab, which doesn't have much for now, so let's navigate
to the play mode tab.
And there they are; the tests that we just created.
So wait.
How do we create edit mode tests?
There was only one option for tests in that create menu right?
And what's the difference between play mode and edit mode tests anyway?
I think I'm gonna leave that for another video.
But for now, let me show you how to create edit mode test, as well.
There's actually two ways to do it.
One is by convention and the other is by configuration.
First, though, I'm going to just dock this test runner to the left of my project folder.
Great.
So.
In Unity, by convention, any script file that's nested anywhere inside of an Editor folder
will be placed into its own DLL called Editor.
Which means if I create a folder called Editor and place a C# script in there, then it will
automatically be added to our edit mode tests, as we can see here in the test runner.
And we can see this Assembly-CSharp-Editor.dll that this script has been associated with.
Now, this is great and all but honestly I've been burned time and time again by frameworks
that rely heavily on convention.
To me it's just to error prone and it requires too much upfront knowledge about how the framework
works.
So instead of doing it this way to just delete this Ed folder that I created what we can
do is navigate up to the root folder and click on create edit mode test assembly folder.
That now appears inside of the edit mode tab of the test runner and we can see we have
another test folder that defaults to test one.
We'll rename that in a second but let's open it up and examine the assembly file that was
created.
We could see that it has the unity include tests constraint but what's also important
to note is that under platforms only the editor platform is checked whereas with the other
test assembly any platform was selected and believe it or not.
That is the only difference between setting up edit mode and play mode tests.
Now writing them and using them as a whole nother story.
But again we're going to save that one for another video to finish up this video.
I think we're going to rearrange this because I personally don't like having folders called
tests one.
Let's make this a little more clear.
First I'm going to rename the editor test assembly to edit mode tests and click apply
and I'm going to rename the file as well to match.
Lastly I'm going to be nesting these two test folders into a parent folder called tests
so I'm just gonna call the folder edit mode.
And now we can do the same thing for our play mode tests.
First I'm going to call the folder play mode.
Whoops.
Renamed the assembly as well.
We'll call this plane all the tests.
And then update the actual assembly name as well.
Lastly I'm going to create in our assets folder here a folder called.
Tests.
And then just dragged the play mode and edit mode folders into that and that's it.
Now we have this folder for edit mode tests but I haven't actually created any.
So go ahead and right click Create testing and then select C# sharp test script.
And now if we look over into the edit mode tab and the test runner we can see we have
a test from our new test script.
Perfect.
Now we're almost ready to write our first tests.
But before we do that we're gonna have to make sure that our tests have access to the
classes that we've written for our game in order to do that.
We'll have to add an assembly to our scripts folder so we'll go ahead and navigate there.
Right click expand the create menu and click on assembly definition and then we'll go ahead
and just rename this main.
Both the file and of course the name of the assembly as well.
Click apply.
Now we'll have to take this assembly and reference it in our edit mode test assembly.
We can do that by clicking on edit mode tests and then underneath the assembly definition
references section we can click the plus sign.
Select the empty reference and then locate and click on the main assembly.
Now once we press apply every class that's associated with that main assembly which are
the ones located in the scripts folder will be available to the edit mode tests.
So at this point we can go ahead and switch to the code editor.
Now the class we're going to be testing this.
Basic counter class.
Is.
Very simple.
And it just serves as a really dumb example that is easy to follow.
What we're going to be testing is this increment method.
We're gonna make sure that the count gets incremented when it's called.
And we're also going to test this small bit of business logic where the count can never
exceed the max count.
All right.
So let's go ahead and open a bar test script.
We can see that it's already populated with a bunch of boiler plate Co.
We can go ahead and just remove that.
And then let's make a new test.
Using a live template.
Shout out to my previous video we can call this test increment and again this is a very
simple example.
I would not structure my tests like this or name them like this one to follow the assign
act and assert paradigm here.
First will assign a variable.
Our system under test which is the counter I like to be explicit.
So I'm just gonna pass and 0 for the count.
Even though it's defaulted 0 in tests I try to be as explicit as possible.
So anyone trying to debug a regression will have to dig too far to understand the state
of the class or systems under test.
Next we're going to act on this by calling increment.
And lastly we're going to just assert our expectation which is that the current account
is equal to 1.
All right.
So in rider we can very easily run this by selecting this little symbol here and clicking
run all.
Now we can see that our test passed.
All right let's do one more just for fun cause I find unit testing fun.
Yes I am a psychopath.
We're gonna call this one test Max count.
All right same thing as before we'll go ahead and assign a variable.
Our system under test.
This time we're gonna give it a count of ten since that's what we expect our max count
to be.
Again I like to be explicit and use cold hard numbers.
We'll call increment.
That's our act phase.
And then lastly we're going to assert that the count is still equal to 10 because it
should not have gone past the max.
OK.
We can navigate down to the unit test explorer we see that our new test shows up.
Go ahead and press play and it passes with flying colors.
So that should be all you need to get started.
Listen I gotta get out of here.
I'm not really sure how this time travel thing works and I think I've probably already overstayed
my welcome.
No way.
Then I need better examples.
Sure I've got my test setup but don't worry man.
Don't worry we'll cover that in another video I promise Sure.
I mean have you seen that in the future.
Hey come on.
Huh.
I guess he had to go maybe in the future.
My MMO is a smashing success.
Oh and maybe I finally surpassed twenty thousand subscribers.
Sure hope so.
In the meantime I should probably learn how to do some unit tests if that's something
you'd like to see.
Then let me know when to comment and leave a like on this video if you enjoyed it.
It really helps out.
Well I'd better get back to work.
Thank you for watching and I'll catch you in the next video.
Time travel.
Special thanks to Dark Rush Photography, NZ, Thomas, Trond, and WayneGlows.