UnitTesting. From CodeBlocks This document is under development by killerbot.
Starting from 7 September 2009. Introduction This document will describe how unit testing can be combined with the Code::Blocks IDE. It will give a hands-on example on a unit testing framework and how it can be used with Code::Blocks. What is Unit Testing Simply put Unit Testing is the discipline and best practice of writing and running little test programs that test little units of code. A class a free function an interface ... There are several unit test frameworks available to help you write, deploy, manage your unit tests. Why Unit Testing When code is written that implements some functionality. The application level; and the integration level of different components, classes, and interfaces. But tests are also needed for the smallest building blocks, the units. UnitTest++ UnitTest++ in brief. UnitTest++ in brief Introduction For background, goals and license details, see: The UnitTest++ home page Noel Llopis' announcement The documentation, while sparse, aims to be practical, so it should give you enough info to get started using UnitTest++ as fast as possible.
This text is almost identical copy of original docs/UnitTest++.html file made by Noel Llopis, I (Peter "Ped" Helcmanovsky) made only some U++ related changes to it - to make it more relevant for U++ users. U++ wrapper The U++ version of UnitTest++ consists of two packages: UnitTest++: The New Choice for C++ Unit Testing? In an earlier post on C++ Unit Testing Frameworks, I came across a relatively new framework by the name of UnitTest++.
At first glance, this framework appealed to me for a couple of reasons: Unlike most of the other frameworks, it is relatively recent, and in developmentOne of the originators of the project is the author of the best comparison of C++ unit testing libraries online. The experience of reviewing several other frameworks should inform the design of a new framework. So, I’ve decided to take a closer look. I’ll start in this post with the basics: how do we write tests, fixtures and suites in UnitTest++? First, we need the UnitTest++ distribution. Jsankey@shiny:~/tools/UnitTest++$ make src/AssertException.cpp src/Test.cpp … Creating libUnitTest++.a library… src/tests/Main.cpp src/tests/TestAssertHandler.cpp … Linking TestUnitTest++… Running unit tests… Success: 162 tests passed. The primary output is libUnitTest++.a at the top level. TDD1. If you’re a typical game developer, you probably don’t write any tests for the code you create.
So how would you feel about not just writing tests, but creating them before the code they are testing? What if I told you those tests don’t even verify that the code you write is correct? “It’s madness,” you might say; “it’s all backwards!” Not really. It all makes sense in its own way. Traditional development. TDD2. Part 1 of this article provided just a glimpse of what was behind the looking glass.
Now we’re ready to dive in all the way and look at how we can apply test-driven development to games. Be warned: the looking glass is very much one-way only. After you try this, you might become test infected and may never be able to go back and write code the way you’ve done up until now. What to test By now you have a pretty good idea of what TDD is and how to apply it. Depending on the code in question, I use one of three main approaches to test that the code is doing what it should. Check output This is the easy one. TEST (TargetingCantLockOnObjectOutsideCone) { TargetingSystem targeting; targeting.SetTransform(...); Vector3 positionBehind (...); CHECK (!
Check state In this situation, you’re checking that a particular operation changes some state. TEST (EntityDoesNotConsumesSpeedPowerupByDefault) { GameEntity entity; SpeedPowerup powerup; CHECK (! Check interaction between objects TDD and Games Graphics. TDD3. After reading the first two parts of this article, you should have enough information to strike boldly and apply test-driven development to your projects.
At first you’re likely to find that the road is somewhat rough and bumpy, though. How do you break up this module into something testable? How can you prevent your tests from becoming a burden to maintain? What exactly should you test? This third and last part will cover some tips that should help smooth out the learning curve and make you more productive from the start. Tips from the trenches When I started doing test-driven development, I was going through the motions, following the advice from Kent Beck’s book, and there was no doubt I was getting a lot of benefit in what I was doing. Use fixtures extensively Using fixtures (objects that automatically set and destroy some state for you for every test), is a great way to keep tests small and to the point.
Keep your tests short and simple.