[pdf-devel] Task 75: pdf_text_get_unicode tests, factored out

[Sylvain Beucler]

Hi,

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 ;)

It allows to easily support a new flag in the future though.

The tests could be further grouped in a single function that would
automatically attempt all combinations, and compute the expected
return value based on a simple formula (something like
!(lang||country) || UTF-16BE).

The current situation is probably clearer and better integrated in the
testing framework though.

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.

-- 
Sylvain

t75.diff
Description: Text Data

pdf-text-get-unicode.c
Description: Text Data