Sign in to follow this  

C++ Unit Testing?

This topic is 3860 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Some that has come up with a large scale project I am involved with that is just starting up is unit testing. Were are going ot be using the cxxtest for doing unit testing but still a little unclear about how to go about this. From my understanding I have function foo and it take whatever parameters. then with cxxtest I pass it good data and bad data and make sure the function return good data and not bad data. Now what I don't understand is where do I use the cxxtest framework? I would image that I don't use it is the project(game engine for instance) and another project the implement the other project(the game engine). So I would basically have 3 project, the game engine, the real project the uses the game engine and then then project the using cxxtest the unit test the game engine. Is this correct? Can anyone else explian this better?

Share this post


Link to post
Share on other sites
I believe that is the typical setup for test harnesses. You have a seperate application that tests the game application.

[not including comments about why i think the test driven development movement is a horrendously awful idea [smile] ]

-me

Share this post


Link to post
Share on other sites
Quote:
Original post by Palidine
I believe that is the typical setup for test harnesses. You have a seperate application that tests the game application.

[not including comments about why i think the test driven development movement is a horrendously awful idea [smile] ]

-me


So you are saying that what I said(have the engine project and the 1 project the using the game engine to build a game and the another project to do unit testing on the engine)?

Also, I would like to hear you comments on driven development movement if you don't mind.

Share this post


Link to post
Share on other sites
Quote:
Original post by RyanZec
Also, I would like to hear you comments on driven development movement if you don't mind.


Now, it's important to note that I am not talking about standard QA test harnesses (scripts that play the game, move the player around and look for crashes/bugs). QA automation is a good thing. But it's good because it doesn't care about implementation details. It's great to automate the testing of design-level things; it's bad to test implementation level things because the implementation is always in flux. So, I am specifically talking about test code whose only purpose is to verify that a specific function is working correctly.

I think that when you start writing test harnesses for many of the functions in your game all you are doing is doubling your work. You have to write double the code for the same functionality, you have to debug 2x the code for the same functionality, test code gets out of date all the time (I tend to refactor systems frequently; refactoring a system would mean refactoring your test code). The short of it is, a bug is a bug. 99% of bugs manifest themselves in obvious ways. You don't need a unit-test harness to either find those bugs or to fix them.

"Test Driven Development" is a buzzword that came out of the dotcom era and should have died with it. It's just silly to me to write code to check code. By that logic shouldn't you also write code to check the code that checks the code?

-me

Share this post


Link to post
Share on other sites
Quote:
Original post by Palidine
I think that when you start writing test harnesses for many of the functions in your game all you are doing is doubling your work. You have to write double the code for the same functionality, you have to debug 2x the code for the same functionality, test code gets out of date all the time (I tend to refactor systems frequently; refactoring a system would mean refactoring your test code). The short of it is, a bug is a bug. 99% of bugs manifest themselves in obvious ways. You don't need a unit-test harness to either find those bugs or to fix them.

"Test Driven Development" is a buzzword that came out of the dotcom era and should have died with it. It's just silly to me to write code to check code. By that logic shouldn't you also write code to check the code that checks the code?


There are a lot of things you don't appreciate about "test driven development". It's not silly to write code to test code, for many reasons. Writing a test first forces you to establish a API from the client's POV, which should significantly reduce the need for refactoring. With a stable API you can then focus on the implementation, and all you have to do to confirm that nothing is broken is run your tests again. Regardless of how bugs manifest themselves, a well written set of tests can tell you exactly what the problem in seconds. They also protect against regressions, because even if a bug is easy to spot, you're just wasting time if you're fixing it again for the 3rd time. It's not uncommon for large pieces of software to use upwards of a million tests, you don't want to think about how much time that's saving someone.

And finally, no one says the person doing the development also has to write the tests... it's usually beneficial to have someone else write some of your test cases.

Share this post


Link to post
Share on other sites
Yea, after discussing this with another developer, I do see this that uniting testing is good. I mean I am going to have to write test code anyways to make sure my code works properly and doing it with a framework like this seems it is help prevent alot fo time searching for bugs.

Share this post


Link to post
Share on other sites
My project is using some unit tests as a part of a total rewrite. We aren't doing test driven development, but we are definitely getting a lot of good use out of unit tests. We make mistakes. All of us do. It's much easier to test a new module by itself in a quick test app than it is to start up the whole game, get to whatever point where that bit of code is used and verify it that way. Make a change to the code? That's easy to test, just rerun the test suite. You don't have to wade through the game itself to try to test it.

Also, we are far from done with our rewrite. Large parts of the game are still not written. However, I know that even though we haven't plugged everything together yet, the individual pieces work as we expect them to. That's pretty nice.

Regardless of whether you do hardcore TDD or not, there is value in quick, well-aimed tests.

Share this post


Link to post
Share on other sites
A few things that have come up in my experience:

1) It's difficult to retrofit Unit testing into an existing code base. Code that was never written to be tested independently looks different than code that was. If you find yourself having to write a lot of stubs to avoid testing the whole library with a single call, that's normal.

2) The more unit tests are used, the more little static libraries your project will have. Since we started adding more unit tests, more of our code is written in libraries that are designed to be tested as a unit. Each of these libraries has a test harness that effectively defines the design requirements of the library. If you fix a bug at some point, a great way to ensure it doesn't happen again is to add a unit (regression) test to check for it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Palidine
It's just silly to me to write code to check code. By that logic shouldn't you also write code to check the code that checks the code?

Since you write the test first, an important step is to run this before doing any "proper" code, and making sure that the test fails. If it doesn't fail then either 1. your test has a bug and isn't actually checking the right thing or 2. the system is smarter than you and you need to track down why it works*.

You combine this with making sure that your tests pass afterwards and you can be pretty sure the test is working fine. And since tests are usually much simpler code (usually minimal or no branching, and a short list of operations) they're not too hard to maintain either.

* This can actually happen, and is nice as it save you a bunch of work [grin]

Share this post


Link to post
Share on other sites

This topic is 3860 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this