Requesting critique of a C unit test environment

Ian Collins wrote:

> There you go, the solution is to hold off all but the most trivial
> refactoring until the end!

That's a joke, guys.

When creating production code, not when researching, after passing a test,
try to simplify, and go in order from easy to hard refactors. Never try a
hard refactor first if there's an easy one available in the neighborhood.

The only exception is renaming things. Name them after their roles
stabilize!

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax

Phlip wrote, On 02/09/07 01:36:
> Ian Collins wrote:
>
>> There you go, the solution is to hold off all but the most trivial
>> refactoring until the end!
>
> That's a joke, guys.
>
> When creating production code, not when researching, after passing a test,
> try to simplify, and go in order from easy to hard refactors. Never try a
> hard refactor first if there's an easy one available in the neighborhood.
>
> The only exception is renaming things. Name them after their roles
> stabilize!

Sometimes when code as been "hacked together" over time the only way to
get a clean design is to start from scratch and design it based on what
you have learned.

There is no one set of rules that is always correct.
--
Flash Gordon

Ian Collins wrote, On 02/09/07 01:35:
> Flash Gordon wrote:
>> Ian Collins wrote, On 01/09/07 08:21:
>>> Ark Khasin wrote:
>
>>>> Assuming that the test code itself must be reasonably dumb (so that
>>>> /its/ errors immediately stand out), that's not terribly realistic:
>>>> imagine a sweep over, say, "int24_t" range. One could only hope to run
>>>> automated tests overnight - on a long night .
>>> It may not appear that way, but it is the reality on any project I
>>> manage. In all (C++) cases, the tests take less time to run than the
>>> code takes to build (somewhere between 50 and 100 tests per second,
>>> unoptimised).
>> This, however, is not always the case. I've written a function of about
>> 20 lines that IIRC required something line 100-200 tests. If test took a
>> similar amount of time to run as the code took to compile. It was doing
>> maths and there where a *lot* of cases to consider.
>>
> Um, I've never seen one like that before, probably because TDD doesn't
> yield that type of code.

That is only true if it produces more complex code. The 20 odd lines of
code resulted from a requirement to implement two simple looking
equations and one simple statement in English. The reason it was so many
test cases was that it was dealing with one angle in the range +/- 270
degrees, one in the range +/-170 degrees and two in the range +/1 6
degrees. The testing had to verify behaviour with every angle in each
quadrant, every angle at 0, 90 etc, every angle just either side etc. It
was the *maths* together with the chances of selecting the wrong
solution from the trig that meant a lot of test cases, not the
complexity of the code.

>> For an audit of the entire piece of SW (rather than just that one
>> function) the customer insisted that we print out all of the module test
>> specs. The stack of A4 paper produced was a couple of feet tall!
>
> Sounds like the US DOD, I'm sure they just weigh or measure
> documentation rather than read it!

You guessed right, but the important thing is the quantity of tests and
therefore the time it would take to run them all.

>> On another project, doing a build of our piece of the SW took 8 hours.
>> Doing a build of all of the SW for the processor took 48 hours. Add
>> testing to that for each build...
>>
> Those were the days. Thank goodness for fast CPUs and distributed building.

Also the larger projects which tie up the processors for just as long
because they are so much more complex.

I know there is still SW that takes hours to build because within the
last few years I have done builds that have taken hours.
--
Flash Gordon

Flash Gordon wrote:
>
> I know there is still SW that takes hours to build because within the
> last few years I have done builds that have taken hours.

Must be huge, the biggest think I build regularly is the OpenSolaris
code base, which takes about 40 minutes on my box.

If a build takes too long, throw more cores at it. If the tools don't
support distributed building, change the tools.

--
Ian Collins.

Ark Khasin wrote:
> Thank you folks for the fruitful discussion
Anyway, I posted a page, http://www.macroexpressions.com/maestra.html in
a hope that some people might find it useful.

-- Ark