[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gEDA-dev: A testing trick .. was.. Re: [PATCH] gschem: Visualfeedback for keyboard commands
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.
_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev