Listen up. You need to test your code.

I’m not talking about giving it a quick eyeball.

I’m not talking about running it and trying a few cases.

I’m not even talking about playtesting.

I’m talking about cold, hard testing.

Let me get you on board first.

The Life of a DigiPen Student

Let’s look at a schedule for a typical Sophomore DigiPen student.

First off, there’s classes:

That’s a pretty standard hellish DigiPen schedule. Especially Wednesday.

Now we need to make sure we’re actually passing classes besides GAM:

Still plenty of time. But unfortunately, we’re humans that require sleep:

I guess now we can throw in some game work time?

Unfortunately, people often have other commitments while at DigiPen as well. I had a part time job that normally absorbed literally the entire weekend. Full double shifts! Some people have kids. Some people visit home. Some people volunteer. Some people travel or relax. Weekends are sometimes just booked for people!

Assuming we’re not talking about a super dev, this seems pretty standard. Lots of work on game on Friday. Some scattered work during the rest of the week. You might fit more game time in personally, but it’s important to remember that not everyone is a crazy super dev that can work for eight hours a day with classes!

Also remember that some people do other activities during the week. Clubs? Student council? Maybe they’re taking dancing classes. Maybe they have a significant other. Maybe they’re a TA.

The point is, there’s a very limited window to work on game, and if they’re a DigiPen student, they’re tired.

Can you imagine, after a full day of just, hell, you sit down to work on game and master doesn’t compile. Not because of you, but because of a team member. Let’s call them Ted.

Ted: The Bad Programmer

Ted didn’t test his damn code. He shoved it to master without thinking and it doesn’t even compile.

So, after about a half an hour of slamming your head against the keyboard and waiting for Ted to respond, you give up and decide to just watch YouTube. You watch this video and feel better.

Ted finally responds and fixes his code after about 5 minutes. You pull it and start to use it in your code. It crashes in the first case you try.

After another five minutes of scrolling through Reddit, Ted finally responds again and this time takes a good half an hour to fix it. By that time, you’ve decided to go to bed.

You wake up the next day ready to work on game, but have to go through all of your classes first. By the time you get to work on it, you’re extremely tired. You decide to truck through it.

But nope, guess what, Ted’s code still doesn’t work. He fixed THAT bug, but he didn’t check a few other edge cases that you need for your code to work. It crashes again.

You decide to take matters into your own hands and try to fix his code yourself. There’s not a comment in sight. He’s not following any coding style guidelines. There’s huge functions that seem to do everything. In fact, there’s even a function frustratingly named “DoEverything()”. It does not, in fact, do everything. It does a subset of all possible actions within the universe. Thus, it does not, even slightly, do everything.

After 45 minutes of trying to read the gibberish Ted wrote, you punt and decide to just ask him to fix it. Again, another hour passes and it seems like Ted fixed it. You have a solid hour to work on your code.

After two days of bad code biting you pretty hard, you have a decision to make. Do you join the dark side and ship it because you’re tired and just want to be done at this point? Or, do you take your time and implement tests and have respect for your teammate’s time?

This is why we write tests. Ted probably took about an hour to write his code, but it ate up days of time for you. You’d be lucky if this was the start of the project and it was fixable. Eventually, that bad code stacks up and you can miss out on weeks because you have to refactor your code or fix old bugs.

Does it make you take a little bit more time? Sure. It might take you multiple hours. Hell, it might take a few extra days, but in the end, you’re saving time for every single person on your team. Every extra hour you spend is an hour granted to everyone on your team. The longer you delay the good solution, the more technical debt you rack up and the more it will cost later on.

Testing isn’t a maybe. It’s a must. Let’s learn all about it.