🔒 Locked

Unit testing

Started by jeroenb Jan 2, 2012 at 4:56 PM 6 replies 1.9k views

Original Post

Jan 2, 2012 at 4:56 PM

I am a newbie concerning the use of unit testing in slightly bigger applications. I choose to use CxxTest as testing platform and have it running as a separate application unit testing some classes.

Currently I have several modules (dll's on Windows) of which some are exported but a lot of the classes in these modules are not exported, meaning I have no access from my external testing tool to them. However I still want to test several of these not exported classes without exporting them all. An option would be to write the exported tests in the module itself and try to link them in the test app. No idea however if CxxTest supports this.

I guess some of you might have faced the same problem. I was wondering if anyone could tell me how to solve it.
Thanks a lot for reading!

Antheus

Jan 2, 2012 at 5:09 PM

Unit tests work in isolation. They test a single function. DLLs are *way* out of scope.

If such a function has dependencies, they are mocked with stubs or whatever, basically removing the dependency with something that is available and fully under control.

The rest falls under integration testing, since tests involve multiple systems (memory allocator, DLL, linker, processes, configurations). Unit testing frameworks are ill-suited for such tasks, since they need to cover special testing setup.

meaning I have no access from my external testing tool to them.[/quote]
Do you have the source code to this code? Include that.

the_edd

Jan 2, 2012 at 5:47 PM

I guess some of you might have faced the same problem. I was wondering if anyone could tell me how to solve it.
Thanks a lot for reading!

Make a static library, which can be linked in to another project containing the tests.

Your dll would wrap this static library (and nothing more).

jeroenb

Jan 2, 2012 at 6:59 PM

Thanks both for the responses.

I know, I am not trying to unit test the DLL, but only some of the classes in them. Testing these classes is possible using unit tests.

[quote name='edd²']Make a static library, which can be linked in to another project containing the tests.

This sounds like a plausible solution. Perhaps I can make multiple build targets: a static library for the unit tests and a dll for the application. Lets see how I can get this working.

coderx75

Jan 3, 2012 at 9:45 PM

I use a central framework application with DLLs linked at run-time and have all code unit tested. I could never remember to write regression tests when writing modules, so I always write modules in test programs separate from the central application. The test program will contain lots of test code and, rather than throw this code away, I include it in the module under a static test() method. Similarly, when moving code into DLLs to use in my project, I simply export a test() function and move the test code into it. The central framework app may also check for the test function for each DLL it loads and run it (this can be switched on/off from the command prompt or in the configuration).

frob

Jan 3, 2012 at 11:04 PM

I know, I am not trying to unit test the DLL, but only some of the classes in them. Testing these classes is possible using unit tests.

You don't unit test classes, either. That is also out of scope.

This was actually part of a recent discussion in a TDD newsgroup I lurk in. Here are selective quotes from it that apply to what you mention:

[font=times new roman,times,serif]> Not only should a good test test a single unit of work, it should test a single characteristic of that work. [/font]

[font=times new roman,times,serif]> A good rule of thumb is whether or not you can easily come up with a single good name for the test that fully describes what it is testing and distinguishes it from your other tests. The name "testExecute()" is a good sign that something is wrong with this test.[/font]

[font=times new roman,times,serif]> A test should not test the coordination and collaboration of different things at the same time.[/font]

[font=times new roman,times,serif]> Keep your tests small, relatively DRY, but most importantly intent revealing. One of the key ways to achieve the last point is through using good names. The convention I now use, which is borrowed from BDD-style tests, is to name my test classes for the class I'm testing and perhaps even a specific method, and end it with Should, and then complete that sentence with each method. So in your case if you're testing the FooComponent's GenerateResponse method, you might do something like:[/font]
[font=times new roman,times,serif]public class FooComponentGenerateResponseShould {
public void ReturnEmptyResponseAndLogErrorOnException()
public void ReturnSuccessResponseAndLogSuccessGivenValidInputs()
}
Sometimes this style can result in rather long class and test names, which is good in that they're explicit, but also a smell if you see lots of AndDoThisOtherThingAndSomethingElse etc. because you're probably violating Single Responsibility Principle at that point.[/font]

Hope that helps give an idea what a unit test generally should cover.

A unit test needs to test a single unit of work. It does not test how it works in concert with other objects or with state or over time. All of those are different kinds of (non-unit) tests.

jeroenb

Jan 8, 2012 at 6:34 PM

Thanks for the quotes Frob! Could you post or PM me a link to the newsgroup? I would be interested to read some of the discussions and hope to learn from it.

For the rest I am already happy if I can implement some tests that prefend bugs from appearing ;-)

frob

Jan 9, 2012 at 6:11 AM

Thanks for the quotes Frob! Could you post or PM me a link to the newsgroup? I would be interested to read some of the discussions and hope to learn from it.

For the rest I am already happy if I can implement some tests that prefend bugs from appearing ;-)

The group is at http://groups.yahoo.com/group/testdrivendevelopment/. It is moderately active, they've accumulated a lot of resources in the archives over the years.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.