Jump to content

View more

Image of the Day

Adding some finishing touches...
Follow us for more
#screenshotsaturday #indiedev... by #MakeGoodGames https://t.co/Otbwywbm3a
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

What does unit testing mean?

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 PragmaOnce   Members   


Posted 12 July 2013 - 04:02 PM

Hey guys.


So a lot of the blogs/tutorials that I have been reading refer to unit testing a lot. It will say that a certain approach makes it easier for unit testing etc.. I did take a glance at the Wikipedia page but it's too much new information for me to solidly grasp. I'm still in high school so I have yet to learn the jargon/glossary associated with a Computer Science course.


So I was wondering if one of you could explain it to me in simpler terms and perhaps a basic implementation of how it is used and why you would use it. 


Thank you.

Edited by PragmaOnce, 12 July 2013 - 04:03 PM.

#2 SiCrane   Moderators   


Posted 12 July 2013 - 04:36 PM

A rather gentle introduction to unit testing is the "Craftsman" series of articles published by Object Mentor. (Click "Craftsman" under "By Topic")

#3 Norman Barrows   Members   


Posted 12 July 2013 - 05:11 PM


unit testing refers to building software in separate pieces with specific functions. each piece is a "unit". the idea is you break down a complex system into its simpler pieces or units. these are simple enough to build and test individually.   an example "unit" might be a bit of code that moves a single unit based on its speed and heading. this would be pretty simple to code and test to make sure its spitting out the right numbers. 


along with unit testing (testing the pieces) comes "integration testing". this is where you hook the pieces together, then test to make sure they work together correctly.


an example of this might be something like stringing your "AI", "turn", and "move" code together, and testing it  to make sure your AI can actually steer and move your units around as desired. The idea being that you've already built and unit tested the "AI", "turn" and "move" code units, and all you have to do is test to make sure you hooked them up correctly.


with modular/unit design, you determine the basic "units" of your program, such as an input unit, a rendering unit, and an update unit  in a game (get_input, drawscreen, move_everything, the 3 basic steps of a game loop).  then you break each unit down into smaller components. your input unit will need keyboard handler and mouse handler components, for example. so you write a keyboard handler, and test just that (unit testing). likewise for a mouse handler. then you combine them to make your input unit (i prefer the term module), and test it,. this is actually both integration testing of the keyboard and mouse units, as well as unit testing of the input unit as a whole.


its all about divide and conquer. building and testing large units becomes easy because they're all built from smaller units that have already been tested and are known to be (reasonably) correct.

Edited by Norman Barrows, 12 July 2013 - 05:12 PM.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"







#4 DareDeveloper   Members   


Posted 13 July 2013 - 07:54 AM

Why do you want to do it? Because you make changes / additions to the existing code at some point and not notice that it breaks functionality that worked previously (who tests every functionality they ever implemented).

A good coverage of functionality with unit tests ensures that you will notice that the code you have modified does no longer work the way it used to work. At some point (possibly integrated into your build process) you will run the unit tests and see if the code still satisfies the conditions. That is pretty much what writing unit tests is about:

you declare that, for example, you want a method to return 10 when you pass 5 as parameter #1 and 2 as parameter #2.


Broken tests might be desired (in that case you update the unit tests) or not (in that case you fix your new code).


You might want to look at TDD (test driven development). With that approach you write the tests first (they will all fail at first) ... then you write the code that makes them succeed.

That approach makes sure you don't write extremely cool classes with dozens of options for later use and never actually use half the code.

You also have to think about responsibilities of modules, scenarios and the architecture before you jump into the implementation ... which is usually a good thing:



Showing examples is a little difficult. It depends a lot on your desired workflow how this is set up. I'd google what options there are for unit testing for your programming language of choice and visit its website.

The real beauty of unit tests can be seen when it is integrated into a continuous integration solution. But I guess you have enough input to process already ...

Edited by DareDeveloper, 13 July 2013 - 08:06 AM.

Given enough eyeballs, all mysteries are shallow.


Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.