[PPL-devel] ppl/tests/Polyhedron numberinput1.cc

[Matthew Mundell]

Abramo Bagnara <abramobagnara at tin.it> writes:

> Matthew Mundell ha scritto:
>> CVSROOT:	/cvs/ppl
>> Module name:	ppl
>> Changes by:	mundell at cs.unipr.it	2005-09-29 11:24:26
>>
>> Modified files:
>> 	tests/Polyhedron: numberinput1.cc
>>
>> Log message:
>> 	Convert test_template to function test, which uses an mpq_class
>> 	checked number.  In function test read number with function input
>> 	(instead of op>>), compare the result of the conversion with an
>> 	expected result, and use is_not_a_number instead of classify.
>>
>> 	Narrow long test invocations.  Add an expected result value to each
>> 	invocation.
>
> Some notes:
>
> 1) You don't need to explicitly pass template arguments to templatic
> functions when these can be deduced from type of arguments.
>
> IMO this is a bad practice.
>
>   Checked_Number<mpq_class, Test_Extended_Number_Policy> q1;
>
>   Result result = Parma_Polyhedra_Library::input<mpq_class,
> Test_Extended_Number_Policy>(q1, f, ROUND_UP);
>
> can be written as a far more readable:
>
> Result result = input(q1, f, ROUND_UP);
>
> (eliminating also the redundant namespace specification)

Thanks.

>
> 2) Don't try to be excessively smart in parsing:
>
>>  test("3^^", "0", "", V_EQ);   // FIX "3", "^^", V_EQ
>
> 3^^ is a regular input up to detection of end
> Then the input is consumed fully.
>
> The policy is that when we find the first character that prove that
> input is terminated or invalid we unget this character and we exit.

This should be included in the documentation.

> 3) Just a doubt (sorry for my annoying paranoia): the expected result of
> every tests has been checked by you? I'd like to avoid an excess of
> trust in my code: tests are only useful if the expected values are
> generated in a very different way wrt the thing that has to be tested :-)

The goal of the test was to verify that the revised checked.cc is
equivalent to the original, so the expected results are intentionally
the values produced by the original code.

Perhaps I should extend this test to be more sure that the revised
checked.cc is sound, and then check in the revisions.  Then a third
person can go through the tests and update the expected results.
Perhaps this third person could be the person documenting the number
format.