Unit Testing in Unity — When Should You Do It?

you know testing okay I love those yeah and I'll turn this one to you when isn't isn't it worth it for an example divided a function that returns an array of array cast hits based on a pattern of rays would you test it um yeah that's a good question I'm trying to find it so I can okay here it is if I have a function that returns an array of Ray cast based on a pattern of rays that you give it I mean basically when it's worth it to tests is when it's fast and there's low overhead I mean the easy answer would be like oh it's always it's always worth it to unit tests

which obviously is not true I mean there are cases where it's not worth it I would say you want to test your business rules absolutely and I mean business rules war talk we're a bunch of game developers so basically your main game mechanics are the rules of your game the fundamental rules of your game world the things that can be messed up by another developer you want to make sure that you test those things it's kind of a broad way to say that but you want expound on that Jason yeah one thing I would say you're so good at like getting down into the I'm off without that umbrella and you go in there and

you hit the details I guess I'll take that as a compliment I will say with those kinds of systems the answer is if it's hard to test if it's if it gets to the point where you're having trouble testing it then don't test it I mean it may sound like a hand wavy answer but the fact of the matter is when you think about a right cast is a ray cast is a collaborator it's something you're working with it's not something you wrote so don't test code that exists test code that you write and so in the case of how do I test ray casts you don't you test if X system has been given

a collection of recast hits and they're all returning vector 3 0 this happens if I return them back and one of the vectors is pointing left and one of them pointing right this happens you don't have to test specifically that the Ray tasks work you have to test that a system when given inputs performs as you expect it to and then you could have another system which tests a if I run this code does it give me back if I hand it ray casts does it give me back my cast it's you don't need to test specifically that in this case this thing happened to match this exact input just test that it does what

you expected to do and realistically you only need to test the critical path in your system like arbitrary arbitrarily testing that red cast happened doesn't really get you anywhere testing that a ray cast if if a ray cast has hit something it should change color test if I fake a ray cast hitting it will it still change color that way you're testing the actual logic of your application and presumably if the Ray casting system works as it by just actively creating ray casts and the thing that receives ray cast works by receiving a ray cast you know if so back so the two will work together and they'll just sort of do what they're supposed

to there's integration tests as well and that's more of the user experience thing at the end of it once you have a system working together you can integrate test the two but realistically like tests that it works you don't need to test the nitty-gritty and that's kind of a big problem with a lot of unit testing sort of diehard attitudes and whatever you point that out where we're not going to toe the company line and say everyone needs the unit test all the time well what we're gonna say is unit test when it's practical yes and the kinds of things are unit tests would be a health system a stat system I would test that

a selection system would work I may feed this election system a raycast to make the selections and I may have a selection system that can perform highlights and I'll feed the highlight system into shader changing color or objects firing do tween events but I won't be testing that do tween events fire and I won't be testing that raycast fire I will test my code which says given these inputs does these outputs happen correctly you know yeah like a for instance let's say you have a game world where you have a pair that walks around there's a some spikes on the floor and when you walk on the spikes you damage the player I wouldn't go

to the trouble of setting all that up in a test and trying to test that the the on trigger gets called and damage occurs I would test the function which probably be like play or take damage and I would I would test all the rules that correspond to that particular function like for instance it can't go below zero or that function cannot accept a negative number you know like if you had like let's say a spiked object in your world where that would damage the player and it had a serialized field that anyone could edit from the editor I mean you don't know what's going in that field it could be a negative number so

you say okay I just all I know is that I've unit tested my player take damage function and it does not accept negative numbers so you're covering your you're covering your bases there I wouldn't say to test the monobehaviour and make sure that no one puts negative numbers there just because it's just not worth it and and that goes back to what we mentioned earlier about separating your unity code from your you know your just basic c-sharp code fundamental code that makes up your game you know like core library code if you will you don't know what you don't always know what unity is gonna do you don't you don't always know what a designer's

gonna do with your code you you know someone might grab a monobehaviour put it on some game object and in a way that you never would have planned for so what's important is to get down to your fundamental code and make sure that at least that's guarded and worried about the worst thing you'll have to worry about is that that game designer will run the game and what they expected to happen didn't happen but what won't happen is that your code won't fundamentally break the player will not go below zero which is a fundamentally incorrect thing to happen in pretty much any game I would think so that's basically that's kind of a thought process

you need to have when you when you get to a decision point you're like should I test this we'll just you need to ask yourself is this fundamental like is it acceptable for for this thing to break and something like player's health going below zero is is not acceptable yeah and kind of a second point on that is you know if you're being very pragmatic about your code like I used to be particularly dogmatic on the idea I liked the idea of a hundred percent test code coverage and having these really swanky suite of tests that I can run constantly and prove that every line of code is ran beautifully and so Eric yeah exactly

just it's not practical it doesn't scale it take forever your team will hate you if you keep doing this and keep pushing the agenda and oh yeah you end up getting into this really muddy situation where your code is so reliant on tests at all your tests break every time you change like there's a lot of things that can go wrong and this and this is from someone saying you should be unit testing like I'm not saying don't do it I am saying be very cognizant of what the problems are and the way you mitigate those is you choose good test the right and on top of that you you were testing the cases that

can go wrong that can cause the most harm so if you can find a way to mitigate that harm you can solve that other side too so a very common thing that I'll do is I write custom inspectors for anything I expect the designer to play with like I don't let them use a specter I haven't customized in some way you can use Odin if you don't wanna write them yourself you can use the straightforward the the attributes for just the basic stuff like ranges and whatever else or just read up on the on validate function that alone will make a lot of your life easier but the long and short of it all is

make sure that you can't get bad inputs if you write an editor inspector such that only valid values can be written into it then you have a lot less problems to worry about in your testing so in general just make a point of ensuring that because there's there's a common phrase garbage in garbage out like you can't you can't recover a system that's been given gibberish to work with like you have to give it good data and give out good data hopefully so in general yeah so just make make it work make it work well make sure that you can't get too many odd cases and then you don't need the test as much and

that stuff you are testing should be stuff that's possible that you can put on a small container test it like a black box and like the litter is called black box testing if I'm gonna get trade specific but yeah you literally go down the road of testing your and put the now puts and that'll cover the majority of your tests related problems you know yeah black Hall says there's there's no way of testing if animations work right I don't I don't mean is animation exactly like as planned but is animation doing anything at all and reacting something not that I know of but again like it's an unsatisfying answer but it doesn't matter like realistically

obviously at some point you enough go into the editor and make sure it works but you shouldn't be testing that it works because at the end of the day the animation system is a third party system that receives it they should be testing it you know unity technology should be testing it and I'm sure they do [Music] you