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

[jemarch]

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  <address@hidden>
                  http://www.jemarch.net
GNU Project       http://www.gnu.org