boundary log usage
Brought to you by:
blep
Menu
▾
▴
An example shows a testcase of boundary class
Logged In: YES
user_id=196852
1) I believe using two distinct "implementations" of a single
symbol in a single executable is illegal C++ (or will be, see the
proposal for dynamic library support in the standard).
2) Yes, it would be a nice feature, though forking is hardly
portable. CppUnit 2 will try to provide more freedom
concerning the execution of test case, so that such thing
could be done.
3) I hardly see how cppunit could know about the resource
you use. Why not simply set rand() to a specific value in your
test setup() ? Anyway, you can implement this yourself using
a 'custom' rand and doing the logging. See the example such
as clocker plug-in to see how to attach extra info to test
result.
Baptiste.
Logged In: YES
user_id=196852
2) To know which test caused the failure, you can use the
BriefTestProgressListener. Just look at the last test name
printed.
Logged In: NO
About boundary class, it's important to a project, let's see an
example:
D -- A -- C
| |
B -- +
There are four classes waiting for test, to B, we must
implement boundary class,
because in most cases, without boundary class, we cann't
run it at all. We
cann't use A or C directely for we doesn't if they are correct.
However boundary
class -- with minor code and can be controlled by our test,
make our do it. Only
after we tested B, C and D, we can test A using them. So
boundary class is
IMPORTANT to us, and we MUST use it in most cases,
providing a support is
necessary to CppUnit. In fact, I've provided a solution covers
Makefile,
CppUnit code standard and its architecture. I don't know the
c++ standard, but
as I showed, with a fine Makefile, we can avoid them by a
group of implicit
rules in Makefile. If you worry the conflict in main.test.cc,
load those *.so in
seperate process, it should can work correctly.
About log system, an interface should be implements just like
CppUnit::log << "some information" << CppUnit::endl;
contrast with
std::cout << "some information" << std::endl;
But it must be implemented in parent-child process model.
class TestListener should run in parent process, otherwise it
cann't capture the
error I've made for current process is killed. With parent-child
process model,
we can collect the results even some of them collapsed.
There is a problem we
must notice: when CppUnit starts a child process to run a
TestCase, we must
record an expiry time set by user, so we can terminate child
process which are
dead lock.
By the way, I hope introduce some assert macros to CppUnit
for:
typically, a test method is just like this
// initiate some resources.
// call my method.
// verify those resources, some cann't be changed.
CPPUNIT_ASSERT_EQUAL(expected, actual) isn't enough to
me for it requires an
overload operator == in target class, why we shouldn't
simplify it? In most
cases, method == only compares source and target object by
bytes, so below four
macros are convenient to me, they also relieves me from
touching tested class
too much.
#define BINARY_EQUAL3(src, dest, member) \ CPPUNIT_ASSERT(memcmp(&(src).member, &
(dest).member, sizeof(typeid((src).member).name())) == 0)
#define BINARY_EQUAL2(src, dest) \ CPPUNIT_ASSERT(memcmp(&(src), &(dest), sizeof
(typeid(src).name())) == 0)
#define ARRAY_EQUAL5(src, dest, member, from, to) \ for (long i = from; i < to; i++) \ CPPUNIT_ASSERT(memcmp(&(src).member
[i], &(dest).member[i], sizeof(typeid((src).member).name()))
== 0)
#define ARRAY_EQUAL4(src, dest, from, to) \ for (long i = from; i < to; i++) \ CPPUNIT_ASSERT(memcmp(&(src)[i], &
(dest)[i], sizeof(typeid(src).name())) == 0)