Test classes

Question

I put together a class yesterday to do some useful work. I started alpha testing, and at some point I realized that I was adding alpha tests to the class itself. It struck me that they did not belong there. After a slight head scratch, I got a test class from a base class that also has access to protected members. I put all the methods related to testing, and set it up and demolished it in the test class, and left the base class lean and medium, as the old saying goes.

After looking here for a while, I found one comment that suggested using this technique, making the testing class a friend of a real class.

In retrospect, both of these methods should have been obvious to me.

What I'm looking for are methods specifically for testing alpha testing / unit testing, without adding to the weight of the tested class.

What methods did you personally use and recommend?

Answer 1

One of the goals of unit testing is to test the interface. for your classes. This means that, generally speaking, you should not test the dirty internals of your class. The unit test is supposed to interact with the public inputs and outputs of your class and verify that the behavior is as expected. That way, you can change the internal implementation of your class without affecting all other objects that depend on it. Obviously, I don’t know the details in your situation, but I would say that, as a rule, if your unit test tries to figure out the private details of a class, you are doing something wrong.

edit: See also: This SO question . Please note that this can be done (top answer), but also note that the second answer (by a small margin) says more or less the same as I mentioned above.

Answer 2

It looks like you do not want unit testing that validates the interface interface correctly. You do not need to change your class at all to do unit testing. If you are looking for a way to check the internal state of your object so that it remains consistent, you should study Design by Contract , which can check the internal state inside the object.

Answer 3

It's good. Usually I also wanted the test class to not only be nozzles from the original, but also in the full version of the DLL / EXE, and also test the "real" compiled class from the "real" DLL / EXE into which it was compiled.

Another method I found is to override the class in the testing tool. Copy the class definition exactly, but make everything public. This allows the test tool to have a white box access to the class, but the actual implementation is still performed from the real class code.

i.e.

class myClass { private: int foo; public: myClass() { foo = 0; } } 

and then:

 class test_myClass { public: int foo; public: test_myClass(); }; void test() { myClass *c = new myClass(); test_myClass *t = (test_myClass*)c; // All methods are called on c. // White-box access is available through t. }; 

Oh ... and DevStudio 2008 now has some really cool module testing capabilities, including the ability to declare a friend assembly, which allows white boxes access to all your inner classes in the assembly under test.

Answer 4

I did a lot of building the framework - basically calling the classes / interfaces that I wanted to test. There was no extra work in the classes.

I also created classes several times that made public methods virtual. I got from them and created test classes / objects. Methods of test objects are called parent (real classes) methods, and all calls and results are recorded. It was more for registration than for testing, but it also worked.

The methods described above, I did before all the hype about unit testing and the like. (around the end of the 1990s)

Then it worked well, but I did not work too much with Junit / nunit material and really want to give them a twist on real projects.

for one method

class thing

{...

public: virtual DoStuff (); , ..};

class ThingTest: public Thing

{

virtual DoStuff ()

{

// write down the call and parameters.

// make a call to the parent

// write the return value

// return the return value

}

};

Answer 5

eJames is right. Testing the device needs to focus on the interface that the inputs to the class produce the correct output. Any private or friend variable is part of the implementation and is not specifically tested.

If you make a mistake in the private routine for the class, then it will show the wrong output.