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.

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:

(http://blog.activelylazy.co.uk/2011/02/09/if-i-had-more-time-i-would-have-written-less-code/)

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 ...