search

susia77 / pdfium

Automatically exported from code.google.com/p/pdfium
0 stars 0 forks source link

PDFium test suite not present. #62

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Tracking bug to follow the progress of getting pdfium tests integrated into the 
environment.

Original issue reported on code.google.com by tsepez@chromium.org on 28 Oct 2014 at 7:53

GoogleCodeExporter commented 9 years ago

Original comment by pal...@chromium.org on 29 Dec 2014 at 8:20

GoogleCodeExporter commented 9 years ago 
I am very interested in these tests.  Even if the tests themselves aren't 
hooked up, seeing what content is being used to test the renderer would be very 
helpful.  Is there a timeline to get that checked in?

Original comment by grimeyat...@gmail.com on 9 Jan 2015 at 12:22

GoogleCodeExporter commented 9 years ago 
@grimey - this is moving, but slowly.

To add some detail to this bug:

In my mind, there are several components to a robust test suite that are 
necessary for pdfium to reach parity with other open source projects.

* Unit tests - based on the gTest framework, these would cover all of fxcrt, 
plus those routines that take simple inputs and produce simple outputs (e.g. 
some of the recent barcode fixes can be tested this way).

* Embedder tests - based on gTest framework, plus a test class that could load 
a file and return control to the framework, so as to permit the test to invoke 
various APIs and check results (think content_browsertests in a chromium world).

* Functional tests - based on something like the current pdfium_test binary, 
but augmented to dump a textual description of the structure of the loaded 
document (think dump render tree in a blink world).  The inputs would be 
hand-crafted files to exercise a specific PDF feature.

* Pixel tests - same as above, but the result is a .bmp for comparison against 
a reference.

* Real world samples - A small number of these would be loaded into the pixel 
tests above. Verification is by .bmp comparison or manually (boo).

Where we are in this process:

* unit-tests - CL https://codereview.chromium.org/835233002/ created the 
pdfium_unittest binary.  Coverage is virtually nil; volunteers to work on 
additional tests are welcome.

* Embedder tests - no such framework exists.  Large portins of the  
sample/pdfium_test.cc code would need to be extracted into a class.  Then 
coverage of the APIs could begin.

* Functional Tests - a crude approach to dumping the structure of a PDF 
document is at https://codereview.chromium.org/791243004/.  Generating 
hand-written test cases is complicated by the need for offset calculations in 
the file, a crude tool for this is at 
https://codereview.chromium.org/791993006/.

* Pixel Tests - we have the samples/pdfium_test binary, but the same issue with 
a lack of input cases and expected resutls.

* Real-world samples - we have a few of these present in the test/ directory, 
but no way of expressing what the expected results might be.

Original comment by tsepez@chromium.org on 9 Jan 2015 at 6:29

GoogleCodeExporter commented 9 years ago 
update: we now have frameworks for unittests, embedder tests, javascript tests, 
and pixel tests, and these are enabled on the build bot for the origin/master 
branch.  Coverage is still extremely spotty.

Original comment by tsepez@chromium.org on 18 Feb 2015 at 9:31