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.
2011-06-18 18:09:21 -07:00
|
|
|
[
|
2011-06-21 14:53:57 -07:00
|
|
|
{ "id": "tracemonkey-eq",
|
2011-06-23 09:48:34 -07:00
|
|
|
"file": "pdfs/tracemonkey.pdf",
|
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.
2011-06-18 18:09:21 -07:00
|
|
|
"rounds": 1,
|
2011-06-21 14:53:57 -07:00
|
|
|
"type": "eq"
|
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.
2011-06-18 18:09:21 -07:00
|
|
|
},
|
|
|
|
{ "id": "tracemonkey-fbf",
|
2011-06-23 09:48:34 -07:00
|
|
|
"file": "pdfs/tracemonkey.pdf",
|
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.
2011-06-18 18:09:21 -07:00
|
|
|
"rounds": 2,
|
|
|
|
"type": "fbf"
|
|
|
|
},
|
|
|
|
{ "id": "html5-canvas-cheat-sheet-load",
|
2011-06-23 09:48:34 -07:00
|
|
|
"file": "pdfs/canvas.pdf",
|
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.
2011-06-18 18:09:21 -07:00
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-06-21 15:14:42 -07:00
|
|
|
},
|
2011-06-24 19:23:29 -07:00
|
|
|
{ "id": "intelisa-load",
|
|
|
|
"file": "pdfs/intelisa.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
|
|
|
},
|
2011-06-21 15:14:42 -07:00
|
|
|
{ "id": "pdfspec-load",
|
2011-06-23 09:48:34 -07:00
|
|
|
"file": "pdfs/pdf.pdf",
|
2011-06-21 15:14:42 -07:00
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-06-26 09:15:33 -05:00
|
|
|
},
|
2011-07-05 13:21:28 -04:00
|
|
|
{ "id": "shavian-load",
|
|
|
|
"file": "pdfs/shavian.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
|
|
|
},
|
2011-06-26 09:15:33 -05:00
|
|
|
{ "id": "sizes",
|
|
|
|
"file": "pdfs/sizes.pdf",
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "eq"
|
2011-06-27 20:13:11 -05:00
|
|
|
},
|
|
|
|
{ "id": "openweb-cover",
|
|
|
|
"file": "pdfs/openweb_tm-PRINT.pdf",
|
2011-06-27 18:28:29 -07:00
|
|
|
"link": true,
|
2011-06-27 20:13:11 -05:00
|
|
|
"rounds": 1,
|
|
|
|
"type": "eq"
|
2011-07-06 00:43:47 +01:00
|
|
|
},
|
|
|
|
{ "id": "openoffice-pdf",
|
|
|
|
"file": "pdfs/DiwanProfile.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-07-13 09:55:13 +01:00
|
|
|
},
|
|
|
|
{ "id": "openofficecidtruetype-pdf",
|
|
|
|
"file": "pdfs/arial_unicode_en_cidfont.pdf",
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
|
|
|
},
|
|
|
|
{ "id": "openofficearabiccidtruetype-pdf",
|
|
|
|
"file": "pdfs/arial_unicode_ab_cidfont.pdf",
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
|
|
|
},
|
|
|
|
{ "id": "arabiccidtruetype-pdf",
|
|
|
|
"file": "pdfs/ArabicCIDTrueType.pdf",
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-07-20 23:17:31 -05:00
|
|
|
},
|
2011-08-19 14:04:34 +01:00
|
|
|
{ "id": "complexttffont-pdf",
|
|
|
|
"file": "pdfs/complex_ttf_font.pdf",
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
|
|
|
},
|
2011-09-17 17:13:22 -05:00
|
|
|
{ "id": "wnv_chinese-pdf",
|
|
|
|
"file": "pdfs/wnv_chinese.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "eq"
|
|
|
|
},
|
2011-07-20 23:17:31 -05:00
|
|
|
{ "id": "i9-pdf",
|
|
|
|
"file": "pdfs/i9.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "eq"
|
2011-08-03 22:22:24 -07:00
|
|
|
},
|
|
|
|
{ "id": "hmm-pdf",
|
|
|
|
"file": "pdfs/hmm.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-08-06 14:41:18 -07:00
|
|
|
},
|
|
|
|
{ "id": "rotation",
|
|
|
|
"file": "pdfs/rotation.pdf",
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-08-14 08:40:22 -05:00
|
|
|
},
|
|
|
|
{ "id": "ecma262-pdf",
|
|
|
|
"file": "pdfs/ecma262.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-08-14 12:26:48 -05:00
|
|
|
},
|
|
|
|
{ "id": "jai-pdf",
|
|
|
|
"file": "pdfs/jai.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-08-28 16:36:58 -05:00
|
|
|
},
|
|
|
|
{ "id": "cable",
|
|
|
|
"file": "pdfs/cable.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "eq"
|
2011-08-30 22:32:56 -05:00
|
|
|
},
|
|
|
|
{ "id": "pdkids",
|
|
|
|
"file": "pdfs/pdkids.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "eq"
|
2011-09-14 21:29:32 -05:00
|
|
|
},
|
2011-09-13 19:23:49 -05:00
|
|
|
{ "id": "artofwar",
|
|
|
|
"file": "pdfs/artofwar.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "eq"
|
2011-09-14 21:45:12 -05:00
|
|
|
},
|
2011-09-17 10:32:42 -05:00
|
|
|
{ "id": "wdsg_fitc",
|
|
|
|
"file": "pdfs/wdsg_fitc.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "eq"
|
2011-09-17 11:23:34 -05:00
|
|
|
},
|
2011-09-14 21:29:32 -05:00
|
|
|
{ "id": "fips197",
|
|
|
|
"file": "pdfs/fips197.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-09-20 15:42:52 -07:00
|
|
|
},
|
|
|
|
{ "id": "txt2pdf",
|
|
|
|
"file": "pdfs/txt2pdf.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-09-21 10:04:21 -07:00
|
|
|
},
|
|
|
|
{ "id": "f1040",
|
|
|
|
"file": "pdfs/f1040.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-09-22 13:17:28 -07:00
|
|
|
},
|
|
|
|
{ "id": "hudsonsurvey",
|
|
|
|
"file": "pdfs/hudsonsurvey.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-09-24 09:44:50 -05:00
|
|
|
},
|
2011-09-23 14:37:44 -07:00
|
|
|
{ "id": "extgstate",
|
|
|
|
"file": "pdfs/extgstate.pdf",
|
|
|
|
"link": false,
|
|
|
|
"rounds": 1,
|
|
|
|
"type": "load"
|
2011-09-24 09:57:59 -05:00
|
|
|
},
|
2011-09-24 09:44:50 -05:00
|
|
|
{ "id": "ibwa-bad",
|
|
|
|
"file": "pdfs/ibwa-bad.pdf",
|
|
|
|
"link": true,
|
|
|
|
"rounds": 1,
|
|
|
|
"skipPages": [ 16 ],
|
|
|
|
"type": "load"
|
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.
2011-06-18 18:09:21 -07:00
|
|
|
}
|
|
|
|
]
|