pdfjs-dist

8244 Commits

1 Branch

1804 Tags

126 MiB

Tree: fa423cfab0

Commit Graph

Author	SHA1	Message	Date
Chris Jones	f7aa149778	Initial import of first test harness The harness (test.py) operates as follows. First it locates executable browsers (or symlinks or scripts) named "[browser][version]", e.g. "firefox4". It then launches the located browsers and asks them to load the file test_slave.html. At the same time, test.py sets up an HTTP server on localhost:8080 (there's a race condition here currently ;). After test_slave loads in the browser(s), it fetches the task manifest (test_manifest.json). The entries in the manifest specify which PDF to load and how many times to cycle through page rendering. This will probably evolve over time. test_slave then performs the requested tasks and POSTs the results back to test.py, which saves them. When all the results of for a task are in, test.py checks them. There are three types of tests currently. "==" tests compare the rendering of a PDF against a master copy. This is not yet implemented because setting up a master copy is complicated. "fbf" tests render all a PDF's pages, then go back to page 1 and render all pages a second time. The renderings from the first round must match the ones from the second round. "load" tests just check that a PDF's pages load without errors. Currently the test harness will only launch a "firefox4" target. This can be a bash script in your pdf.js checkout, pdf.js/firefox4, something like the following #!/bin/bash dist="/path/to/firefox4/installation" profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'` $dist/firefox -no-remote -profile $profile $* rm -rf $profile (Yes, this script doesn't clean up properly on early termination.) It's possible to run the tests in a normal browsing session, but that might be annoying. With that set up, run the harness like so python test.py If all goes well, you'll see all "TEST-PASS" messages printed to stdout. If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL" printed to stdout.	14 years ago
Chris Jones	7c024b89aa	Initial import of first test harness The harness (test.py) operates as follows. First it locates executable browsers (or symlinks or scripts) named "[browser][version]", e.g. "firefox4". It then launches the located browsers and asks them to load the file test_slave.html. At the same time, test.py sets up an HTTP server on localhost:8080 (there's a race condition here currently ;). After test_slave loads in the browser(s), it fetches the task manifest (test_manifest.json). The entries in the manifest specify which PDF to load and how many times to cycle through page rendering. This will probably evolve over time. test_slave then performs the requested tasks and POSTs the results back to test.py, which saves them. When all the results of for a task are in, test.py checks them. There are three types of tests currently. "==" tests compare the rendering of a PDF against a master copy. This is not yet implemented because setting up a master copy is complicated. "fbf" tests render all a PDF's pages, then go back to page 1 and render all pages a second time. The renderings from the first round must match the ones from the second round. "load" tests just check that a PDF's pages load without errors. Currently the test harness will only launch a "firefox4" target. This can be a bash script in your pdf.js checkout, pdf.js/firefox4, something like the following #!/bin/bash dist="/path/to/firefox4/installation" profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'` $dist/firefox -no-remote -profile $profile $* rm -rf $profile (Yes, this script doesn't clean up properly on early termination.) It's possible to run the tests in a normal browsing session, but that might be annoying. With that set up, run the harness like so python test.py If all goes well, you'll see all "TEST-PASS" messages printed to stdout. If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL" printed to stdout.	14 years ago

Author

SHA1

Message

Date

Chris Jones

f7aa149778

Initial import of first test harness

The harness (test.py) operates as follows.  First it locates executable browsers
(or symlinks or scripts) named "[browser][version]", e.g. "firefox4".
It then launches the located browsers and asks them to load the file
test_slave.html.  At the same time, test.py sets up an HTTP server on
localhost:8080 (there's a race condition here currently ;).  After
test_slave loads in the browser(s), it fetches the task manifest
(test_manifest.json).  The entries in the manifest specify which PDF
to load and how many times to cycle through page rendering.  This will
probably evolve over time.  test_slave then performs the requested
tasks and POSTs the results back to test.py, which saves them.  When
all the results of for a task are in, test.py checks them.

There are three types of tests currently.  "==" tests compare the
rendering of a PDF against a master copy.  This is not yet implemented
because setting up a master copy is complicated.  "fbf" tests render
all a PDF's pages, then go back to page 1 and render all pages a
second time.  The renderings from the first round must match the ones
from the second round.  "load" tests just check that a PDF's pages
load without errors.

Currently the test harness will only launch a "firefox4" target.  This
can be a bash script in your pdf.js checkout, pdf.js/firefox4,
something like the following

 #!/bin/bash
 dist="/path/to/firefox4/installation"
 profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'`
 $dist/firefox -no-remote -profile $profile $*
 rm -rf $profile

(Yes, this script doesn't clean up properly on early termination.)
It's possible to run the tests in a normal browsing session, but that
might be annoying.  With that set up, run the harness like so

 python test.py

If all goes well, you'll see all "TEST-PASS" messages printed to
stdout.  If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL"
printed to stdout.

14 years ago

Chris Jones

7c024b89aa

Initial import of first test harness

The harness (test.py) operates as follows.  First it locates executable browsers
(or symlinks or scripts) named "[browser][version]", e.g. "firefox4".
It then launches the located browsers and asks them to load the file
test_slave.html.  At the same time, test.py sets up an HTTP server on
localhost:8080 (there's a race condition here currently ;).  After
test_slave loads in the browser(s), it fetches the task manifest
(test_manifest.json).  The entries in the manifest specify which PDF
to load and how many times to cycle through page rendering.  This will
probably evolve over time.  test_slave then performs the requested
tasks and POSTs the results back to test.py, which saves them.  When
all the results of for a task are in, test.py checks them.

There are three types of tests currently.  "==" tests compare the
rendering of a PDF against a master copy.  This is not yet implemented
because setting up a master copy is complicated.  "fbf" tests render
all a PDF's pages, then go back to page 1 and render all pages a
second time.  The renderings from the first round must match the ones
from the second round.  "load" tests just check that a PDF's pages
load without errors.

Currently the test harness will only launch a "firefox4" target.  This
can be a bash script in your pdf.js checkout, pdf.js/firefox4,
something like the following

 #!/bin/bash
 dist="/path/to/firefox4/installation"
 profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'`
 $dist/firefox -no-remote -profile $profile $*
 rm -rf $profile

(Yes, this script doesn't clean up properly on early termination.)
It's possible to run the tests in a normal browsing session, but that
might be annoying.  With that set up, run the harness like so

 python test.py

If all goes well, you'll see all "TEST-PASS" messages printed to
stdout.  If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL"
printed to stdout.

14 years ago

541 Commits (fa423cfab0b6f2d1b42c7de24fca39e3be834dc2)