Hi Sylvain.
I'm working on task 75 to complete the pdf_get_unicode testsuite.
The task asks to take the previous 54 tests and modify them to support
the PDF_TEXT_UNICODE_WITH_NUL_SUFFIX flag, to create 54 new tests.
The tests follow a pattern: exhaustively combine the function
parameters and flags. This means lots of the tests are copy/pasted
version of earlier tests.
To write the tests I tried to factor out the existing ones, eventually
defining each test by the parameters it tests:
struct test_params /* No Encoding BOM Empty Lang
Country NUL PDF_OK? */
tests_params[] = {{ 1, PDF_TEXT_UTF8, 0, 0, 0, 0,
0, 1 },
{ 2, PDF_TEXT_UTF8, 1, 0, 0, 0,
0, 1 }};
The tests call a generic function with the array index:
START_TEST(pdf_text_get_unicode_001) { mytest( 1); } END_TEST
START_TEST(pdf_text_get_unicode_002) { mytest( 2); } END_TEST
I'm not sure this is the Right Way to define tests. Pushed to its
limit, this model means providing an alternate implementation of the
tested function ;)
I think that it is reasonable.
An alternative would be to generate pdf-text-get-unicode.c using some
script and/or the C pre-processor.
I finished implementing this idea, and I attach a patch. Since this is
essentially rewriting the C source, I also attach it as a separate
plain file.
What's lacking is documenting each test. Since this would be as
tedious as writing the tests themselves (i.e. it would require
copy/pasting and adapting the existing tests' descriptions), I'm
looking for alternatives :)
It may be clearer to document the general pattern of the tests rather
than each tests separately. It actually took me a while to figure out
what the existing tests exactly did for that reason: there was lots of
specific information for each test, but little information about the
global test pattern (what parameters varied, what general combinations
produced !PDF_OK, etc.).
Hopefully the big tests_params array makes this more
straightforward now :)
I talked with Aleksander on #pdf and he's OK with the changes, but
suggested this was brought to the list too.
Regarding the documentation of the tests, I would write down a single
test documentation block documenting all tests, like:
/*
* Test: pdf_text_get_unicode_001-061
* Description:
* Blah blah
* Success conditions:
* Blah blah
*/
The patch is ok for me. I will install it as soon your papers are ok.
--
Jose E. Marchesi <[email protected]>
http://www.jemarch.net
GNU Project http://www.gnu.org
