ppl/tests/Polyhedron numberinput1.cc

CVSROOT: /cvs/ppl Module name: ppl Changes by: mundell@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.
Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/tests/Polyhedron/numberinput1....

Matthew Mundell ha scritto:
CVSROOT: /cvs/ppl Module name: ppl Changes by: mundell@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)
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.
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 :-)

Abramo Bagnara abramobagnara@tin.it writes:
Matthew Mundell ha scritto:
CVSROOT: /cvs/ppl Module name: ppl Changes by: mundell@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:
- 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.
- 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.
- 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.
participants (3)
-
Abramo Bagnara
-
Matthew Mundell
-
Matthew Mundell