#2 Passing "state" around?

[Anonymous]

Hi Folks:

I am trying to use CUnit to convert our unit tests, and I'm having several
problems.

One problem is that my setup and teardown routines need to be able to
pass state back and forth between them and the unit tests.

For example, if I want to create a test jig in "setup()", and I don't want
to use globals (which are evil), how do I tell my unit tests what the setup
function has done? (Answer: there is no way without globals)

I'd love to see a "void *" being the prototype for the setup, teardown,
and unit tests, and have the framework pass this around. (It would be up
to the setup, teardown, and tests to agree on what this "pointed to",
who "alloced" it, who "freed" it, etc.)

Before I start hacking on the CUnit sources, I thought I might ask if you
guys would agree this is a good addition.

If you'd like, I'd be glad to help code/support this feature.

Thanks.

[Mike Whittaker]

Logged In: YES
user_id=323126

An alternative would be a "name,value" registry used by all
functions, with the interface being a get_ and a set_
function. Your setup could record things here, and they
could be inspected by the test function.

I /would/ like a test (and instance setup/teardown) to be
able to find its own name (and/or suite index) so I could
have one common parameterised test subfunction (and
setup/teardown) which factored out most/all of the work.

Again, maybe a CUnit function that reported the test name,
index and suite name would assist here.

By "index" in the above, I mean the index in a CU_TestInfo
table, or order in which tests were added to the test registry.

[Jerry S.]

Logged In: YES
user_id=295275

Thanks for the thoughts. Sorry not to have noticed them until
now.

You can get the name of the currently running test and suite
during a test run. These are available by examining the
pName member of the pointers returned by the
CU_get_current_test() and CU_get_current_suite() functions.

You could also keep track of the pointers returned by the
CU_add_test() and CU_add_suite() functions. These same
pointers are returned by the functions mentioned above when
being run. Your registration function might be able to store
these pointers for later lookup.

Is that enough, or do you really need to know the index of the
test being run? You can find it currently by using
CU_get_current_suite() during the run, then walking the linked
list of tests of its pTest member until you find the current
test. This is a hazardous degree of coupling between the
framework and your test code, though.

As you mentioned, the use of globals is not ideal, but file
statics are not evil. Is it possible to have your setup,
teardown, and test functions in a single file to allow using this
approach?

If these approaches do not meet your needs and you still
think modifying the framework will help, please continue the
discussion.

Thanks again, Jerry