Recent changes to bugs

BRINGUP and TAKEDOWN are location dependent

2004-09-27T21:20:53Z

In the file containing the test definitions, all of the
functions are called in the same order that they exist
in the file, including the bringup and takedown functions.

BRINGUP should be called before any of the tests, and
TAKEDOWN should be called after all of the tests.

Otherwise whats the point in giving the functions
special names?

I like to have my bringup and takedown functions both
at the beginning of the file, because if you edit one
you will likely edit the other.

Here is an example that will probably cause a runtime
error:

char* pString;

void __CUT_BRINGUP__TestString( void )
{
pString = malloc(256);
}
void __CUT_TAKEDOWN__TestString( void )
{
free(pString);
}

void __CUT__TestSomeStringTest()
{
strcpy(pString, "hello world");
ASSERT( 0 == strcmp("hello world", pString), "String
is hello world" );
}

Changes for generated code

2003-05-22T17:59:48Z

Template changes for version 2.3:

In "print_integer_as_expected", cast fourth arg to
unsigned long as shown:

printf( "(signed) %d (unsigned) %u (hex) 0x%08lX", i,
i, (unsigned long) i );

In "__cut_check_errors", change final "else return 1" to
fall-through as shown:

} ;
return 1;

Both changes prevent warning errors from picky compilers.

Thanks!

Jack <sarvela@cs.utexas.edu>

Failed test returns exit code 0

2003-03-14T19:27:35Z

When a bring-up fails, a non-zero result code is
returned. But, when a normal test fails, CUT's test
runner returns a zero result code, as if everything
passed. This can confuse IDE environments and shell
scripts.

Makefile should be OS agnostic.

2003-03-13T00:20:39Z

The supplied Makefile comes pre-configured with
-D__LINUX__ in it. This is because there apparently is
no predefined compiler macro to identify whether or not
it's compiling under Linux. I know there has to be
some kind of predefined compiler macro for this purpose.

The Makefile should be OS agnostic, even if the
compiler macro can't be depended upon. Suitable
documentation should be written to explain it if necessary.

Bringup failure doesn't terminate test.

2003-03-11T19:59:34Z

Create a unit test where the bring-up function is
guaranteed to fail, and which has at least one normal
test under it, also guaranteed to fail. Run cutgen on
the unit test source, compile it, and execute it. See
attached file -- it's already got the test case
pre-made in it.

Note how the test in the bring-up, which is itself a
regular test, fails but does not terminate the
subsequent execution of the bring-up's dependent tests.
In other words, CUT's test runner enables the inner
code to execute even though it knows full well that the
environment hasn't been created/established
successfully for it.

If the execution of a bring-up failed, it's likely that
a pointer or handle will be set to NULL, zero, or some
other illegal value. The contained unit tests assume
that the environment is established, and therefore, do
not regularly check these values to ensure they're
correct. As a result, executing a unit test program
can potentially crash in the event an environment
wasn't established correctly.

Note also that a teardown for a failed bring-up is also
executed. For the same reasons as above, it could also
crash the system or the process (freeing memory that
was never actually allocated, closing a window that was
never opened, etc). Therefore, it too should not be
allowed to run if an environment bring-up failed.