views:

89

answers:

2

Hi everyone,

Now i'm expericing a problem about unit test, We have developed a platform with C++, and this platform include 2 layers, one is engine layer, the other one is widget layer, and i'm a dev in widget layer, The widget layer used by client app (those app is our product), now the problem is this:

1, We want to add some unit test for widget layer to enhance our whole platform quality and reliability, but in fact, this platform has been release for several versions, so now, what's kind of unit test could be most suitable for our project? To add some unit test in kinds of validation/bad input/path cover/stress or to add some unit test that simulate the client senario? I think the former one will enhance code coverage very well, but i also think about that if we can simulate how our client using those api in their application, those unit test maybe more make sense for our platform, right?

2, just as i mentioned before, i'm in widget layer which is above and depended on engine layter, but we has no authority for engine layer code, and almost all widget api could call in engine layer, so it's diffcult for us to implement good path cover unit test for those api, because we have no idea(and no document)about engine layer code, but i still want to ask, is there any ways, tools or frameworks could make someone write high quality unit test to cover path for those black box api?

Thanks very much.

A: 

Since you work in the widget API, and do not have access to the engine code, write your own engine instead.

Use this engine to test the widget code. The engine can be very thin, almost not functional at all, doing just the minimum to fool the widget layer into believing it works.

The test engine can even be a shim on top of the real engine. How you implement this varies a lot depending on the environment you work in, but in Windows it could be that a DLL forwards all its calls to the "real" DLL, but logs calls to it first.

Another technique: since you do have access to the Widget layer, and the engine API is very big, you can reprogram the Widget layer to use the "test layer" in only some places, but the real layer in remaining places. This can be combined with the shim technique.

Suitable (or available) tools for generating stubs or stub engines varies a lot depending on which language and environment you are working in.

Also see this DirectDraw hack for inspiration, it started life as a thin, logging shim upon the original DirectDraw implementation.

Amigable Clark Kant
Good point! so that we can work around engine layer to test it! but the problem is the engine layer it too big to replace :( even a fake layer still need very big effort, so is there any tool could help do that?
vvvvv810505
A: 

You do not mention what widget framework you are using but Qt has a test framework that allows the test code to trigger the same Qt signals that normally get generated by user input (for example mouse clicks or key pressed). See this for more detail.

If you are using a different framework, there might be similar functionality that you could use.

doron
Thanks for you suggestion
vvvvv810505