gEDA-dev: A testing trick .. was.. Re: [PATCH] gschem: Visual feedback for keyboard commands

[al davis]

On Friday 01 June 2007, Ales Hvezda wrote:
> On a slightly different topic...
>
> I've been noticing that some of the code cleanup patches have
> been changing:
>
> if (...) {
>   single_statement;
> }
>
> to:
>
> if (...)
>   single_statement;
>
> Please, please, please don't go out of your way to make such
> changes.

To back up Ales ...

Here's a debug and testing trick I use.  It's a hack, but it 
really tells me a lot.

I have a header file "io_trace.h" that has some macros.  Feel 
free to take it if you want.  There are some other testing 
goodies in there too.

To do a coverage analysis, without any other tools..

Do global search and replace:

replace "{" with "{untested();"
(without the quotes)

Compile with "-DTRACE_UNTESTED"

It produces a big spew when the program is run, that can be 
tamed with grep and sort.  Run the full regression suite on it.

Now remove the "untested();" on the lines that are identified in 
the output.

See where "untested();" remains.  This is code that the 
regression suite doesn't reach.  Do I need better testing?  
Does this code really do anything?

I leave this in as documentation.

The untested macro is:
====================
#ifdef TRACE_UNTESTED
#define untested() (printf("@@#\n@@@:%s:%u:%s\n", \
			   __FILE__, __LINE__, __func__))
#else
#define untested()
#endif
====================

The @ signs are there to provide a pattern that is easy to grep.

So, I go a step further than Ales ..  Every if has an else, even 
if it is empty.  If nothing else, it is a place to tack 
the "untested();" macro call.