A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'm a student software engineering currently in charge of the quality assurance of a project... I made all kind of plans on how to improve software quality, and writing unit tests during implementation is one of them.
Now, I was trying to use a tool for automated unit testing, currently my eye falls on CUnit, but I don't think the exact tool I'm using is the issue: I'm wondering where the "proper" place is to place my unit tests ? What is the normal way to design this ?
We currently have 3 submodules within our product - is the proper way to design it to make a huge unit test file for each of those modules, or is it to include the actual unit tests within the files the code is in (so for example, when you have a SocketHandler that needs testing, include the unit tests for the SocketHandler in SocketHandler.h or .c), or is the proper way to make one extra file per class and store all unit tests for that class inside that file ?
Anyway, these are the kind of issues I'm playing with, and I'm pretty sure some of you guys have experienced working in "real" projects using automated unit testing and I'm wondering how you included the unit tests within your design...
Thanks in advance for any responses; and I apologize for my bad English, it's not my native language... :)
Thursday, December 01, 2005
I'll personally always write a new file per unit test/class, although classes themselves are sometimes collated several in a file if it makes sense to do so. You'll want to run tests in various groups and one test per file should allow you more control in defining groups.
PS: don't forget the acceptance & integration tests.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz