Jump to content
  • Advertisement
  • entries
  • comments
  • views

Unit Tests Con't

Sign in to follow this  
Mike Bossy


Quick post to answer Jason's questions.

1. Do tests look for exceptional cases or functionality of the class?

Unit tests are meant to tests the core functionality of the object. I go by the mantra of writing tests to cover parameters going in and return values going out. By that I mean for every parameter going in I'm testing a valid value and an invalid value. I'll also make sure I have tests that cover all valid return values. Should end up being around 1-5 tests per method depending on the number of parameters and return values.

Things like corner test cases would be left for a formal test pass if you have a test team. Like most of us you probably don't :). In that case I do try and add such cases to my unit tests if they pop into my mind or when I come across a related bug. Generally any time I find a bug in a class I try to figure out why my unit tests didn't catch it and then write a new test that will catch it. Once again this may seem useless since I've already found the bug but refactoring can bring bugs back from the dead. I want a test there to catch it if it does.

2. Do you create tests for every method on very class?

Yes. This is the essence of unit testing. The goal is to have a list of objects that you can really trust. The only way to do that is to test everything. This can be a daunting task with older code so I suggest starting out writing unit tests whenever you create a new class and then slowly go back and write tests for your old code. Odds are you are never going to get 100% coverage on your old code but you'll find that a lot of old code disappears anyways.

If you have classes that have 100+ methods then most likely it's time to do some refactoring. One of the things about OO design is that it's easy to end up with bloated base classes that need to be split out. It's an evil that hits us all. I target a major refactoring pass after every major project to see what's worked and what hasn't. This refactoring is the very reason why you want the unit tests around. Saves you a lot of pain.
Sign in to follow this  

1 Comment

Recommended Comments

Mike - thanks for the replies. My problem is that my huge base class is a very logical progression from a couple of years of development. The reason that it has so many methods is that it represents a 3D entity in a software system that is intended to render 3D entities - there really isn't a logical reason to break up the functionality (in my mind anyways).

I still like the idea of unit tests though. Regardless of if the methods are contained within 10 classes or 1 class I still have to write the tests for 100 methods, so they are still a valid task for me to do. Do you have any further examples or maybe a reference for me to get started? I am just having a hard time figuring out how to test a method where you set an entity's position - it doesn't immediately present itself.

Like you said, I will start with the new functionality and continue on with the other classes later on. Thanks again for the information!

Share this comment

Link to comment

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
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!