2011-06-22 07:14:42 +09:00
|
|
|
import json, os, sys, subprocess, urllib2
|
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-19 10:09:21 +09:00
|
|
|
from BaseHTTPServer import BaseHTTPRequestHandler, HTTPServer
|
2011-06-22 06:53:57 +09:00
|
|
|
from urlparse import urlparse
|
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-19 10:09:21 +09:00
|
|
|
|
2011-06-22 17:35:46 +09:00
|
|
|
def prompt(question):
|
|
|
|
'''Return True iff the user answered "yes" to |question|.'''
|
|
|
|
inp = raw_input(question +' [yes/no] > ')
|
|
|
|
return inp == 'yes'
|
|
|
|
|
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-19 10:09:21 +09:00
|
|
|
ANAL = True
|
2011-06-22 06:53:57 +09:00
|
|
|
DEFAULT_MANIFEST_FILE = 'test_manifest.json'
|
2011-06-23 10:37:58 +09:00
|
|
|
EQLOG_FILE = 'eq.log'
|
2011-06-22 06:53:57 +09:00
|
|
|
REFDIR = 'ref'
|
2011-06-22 17:35:46 +09:00
|
|
|
TMPDIR = 'tmp'
|
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-19 10:09:21 +09:00
|
|
|
VERBOSE = False
|
|
|
|
|
|
|
|
MIMEs = {
|
|
|
|
'.css': 'text/css',
|
|
|
|
'.html': 'text/html',
|
|
|
|
'.js': 'application/json',
|
|
|
|
'.json': 'application/json',
|
|
|
|
'.pdf': 'application/pdf',
|
|
|
|
'.xhtml': 'application/xhtml+xml',
|
|
|
|
}
|
|
|
|
|
|
|
|
class State:
|
|
|
|
browsers = [ ]
|
|
|
|
manifest = { }
|
|
|
|
taskResults = { }
|
|
|
|
remaining = 0
|
|
|
|
results = { }
|
|
|
|
done = False
|
2011-06-22 17:35:46 +09:00
|
|
|
masterMode = False
|
|
|
|
numErrors = 0
|
|
|
|
numEqFailures = 0
|
|
|
|
numEqNoSnapshot = 0
|
|
|
|
numFBFFailures = 0
|
|
|
|
numLoadFailures = 0
|
2011-06-23 10:37:58 +09:00
|
|
|
eqLog = None
|
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-19 10:09:21 +09:00
|
|
|
|
|
|
|
class Result:
|
|
|
|
def __init__(self, snapshot, failure):
|
|
|
|
self.snapshot = snapshot
|
|
|
|
self.failure = failure
|
|
|
|
|
|
|
|
|
|
|
|
class PDFTestHandler(BaseHTTPRequestHandler):
|
|
|
|
# Disable annoying noise by default
|
|
|
|
def log_request(code=0, size=0):
|
|
|
|
if VERBOSE:
|
|
|
|
BaseHTTPRequestHandler.log_request(code, size)
|
|
|
|
|
|
|
|
def do_GET(self):
|
2011-06-22 06:53:57 +09:00
|
|
|
url = urlparse(self.path)
|
|
|
|
# Ignore query string
|
|
|
|
path, _ = url.path, url.query
|
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-19 10:09:21 +09:00
|
|
|
cwd = os.getcwd()
|
2011-06-22 06:53:57 +09:00
|
|
|
path = os.path.abspath(os.path.realpath(cwd + os.sep + path))
|
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-19 10:09:21 +09:00
|
|
|
cwd = os.path.abspath(cwd)
|
|
|
|
prefix = os.path.commonprefix(( path, cwd ))
|
|
|
|
_, ext = os.path.splitext(path)
|
|
|
|
|
|
|
|
if not (prefix == cwd
|
|
|
|
and os.path.isfile(path)
|
|
|
|
and ext in MIMEs):
|
|
|
|
self.send_error(404)
|
|
|
|
return
|
|
|
|
|
|
|
|
if 'Range' in self.headers:
|
|
|
|
# TODO for fetch-as-you-go
|
|
|
|
self.send_error(501)
|
|
|
|
return
|
|
|
|
|
|
|
|
self.send_response(200)
|
|
|
|
self.send_header("Content-Type", MIMEs[ext])
|
|
|
|
self.end_headers()
|
|
|
|
|
|
|
|
# Sigh, os.sendfile() plz
|
|
|
|
f = open(path)
|
|
|
|
self.wfile.write(f.read())
|
|
|
|
f.close()
|
|
|
|
|
|
|
|
|
|
|
|
def do_POST(self):
|
|
|
|
numBytes = int(self.headers['Content-Length'])
|
|
|
|
|
|
|
|
self.send_response(200)
|
|
|
|
self.send_header('Content-Type', 'text/plain')
|
|
|
|
self.end_headers()
|
|
|
|
|
|
|
|
result = json.loads(self.rfile.read(numBytes))
|
2011-06-22 06:53:57 +09:00
|
|
|
browser, id, failure, round, page, snapshot = result['browser'], result['id'], result['failure'], result['round'], result['page'], result['snapshot']
|
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-19 10:09:21 +09:00
|
|
|
taskResults = State.taskResults[browser][id]
|
2011-06-22 06:53:57 +09:00
|
|
|
taskResults[round].append(Result(snapshot, failure))
|
|
|
|
assert len(taskResults[round]) == page
|
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-19 10:09:21 +09:00
|
|
|
|
|
|
|
if result['taskDone']:
|
|
|
|
check(State.manifest[id], taskResults, browser)
|
2011-06-22 07:14:42 +09:00
|
|
|
# Please oh please GC this ...
|
|
|
|
del State.taskResults[browser][id]
|
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-19 10:09:21 +09:00
|
|
|
State.remaining -= 1
|
|
|
|
|
|
|
|
State.done = (0 == State.remaining)
|
2011-06-22 16:05:45 +09:00
|
|
|
|
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-19 10:09:21 +09:00
|
|
|
|
2011-06-22 17:35:46 +09:00
|
|
|
def setUp(manifestFile, masterMode):
|
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-19 10:09:21 +09:00
|
|
|
# Only serve files from a pdf.js clone
|
|
|
|
assert not ANAL or os.path.isfile('pdf.js') and os.path.isdir('.git')
|
|
|
|
|
2011-06-22 17:35:46 +09:00
|
|
|
State.masterMode = masterMode
|
|
|
|
if masterMode and os.path.isdir(TMPDIR):
|
|
|
|
print 'Temporary snapshot dir tmp/ is still around.'
|
|
|
|
print 'tmp/ can be removed if it has nothing you need.'
|
|
|
|
if prompt('SHOULD THIS SCRIPT REMOVE tmp/? THINK CAREFULLY'):
|
|
|
|
subprocess.call(( 'rm', '-rf', 'tmp' ))
|
|
|
|
|
|
|
|
assert not os.path.isdir(TMPDIR)
|
|
|
|
|
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-19 10:09:21 +09:00
|
|
|
testBrowsers = [ b for b in
|
2011-06-22 17:35:46 +09:00
|
|
|
( 'firefox5', )
|
|
|
|
#'chrome12', 'chrome13', 'firefox4', 'firefox6','opera11' ):
|
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-19 10:09:21 +09:00
|
|
|
if os.access(b, os.R_OK | os.X_OK) ]
|
|
|
|
|
2011-06-22 06:53:57 +09:00
|
|
|
mf = open(manifestFile)
|
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-19 10:09:21 +09:00
|
|
|
manifestList = json.load(mf)
|
|
|
|
mf.close()
|
|
|
|
|
2011-06-22 07:14:42 +09:00
|
|
|
for item in manifestList:
|
|
|
|
f, isLink = item['file'], item.get('link', False)
|
|
|
|
if isLink and not os.access(f, os.R_OK):
|
|
|
|
linkFile = open(f +'.link')
|
|
|
|
link = linkFile.read()
|
|
|
|
linkFile.close()
|
|
|
|
|
|
|
|
sys.stdout.write('Downloading '+ link +' to '+ f +' ...')
|
|
|
|
sys.stdout.flush()
|
|
|
|
response = urllib2.urlopen(link)
|
|
|
|
|
|
|
|
out = open(f, 'w')
|
|
|
|
out.write(response.read())
|
|
|
|
out.close()
|
|
|
|
|
|
|
|
print 'done'
|
|
|
|
|
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-19 10:09:21 +09:00
|
|
|
for b in testBrowsers:
|
|
|
|
State.taskResults[b] = { }
|
|
|
|
for item in manifestList:
|
|
|
|
id, rounds = item['id'], int(item['rounds'])
|
|
|
|
State.manifest[id] = item
|
|
|
|
taskResults = [ ]
|
|
|
|
for r in xrange(rounds):
|
2011-06-22 06:53:57 +09:00
|
|
|
taskResults.append([ ])
|
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-19 10:09:21 +09:00
|
|
|
State.taskResults[b][id] = taskResults
|
|
|
|
|
|
|
|
State.remaining = len(manifestList)
|
|
|
|
|
|
|
|
for b in testBrowsers:
|
|
|
|
print 'Launching', b
|
2011-06-22 06:53:57 +09:00
|
|
|
qs = 'browser='+ b +'&manifestFile='+ manifestFile
|
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-19 10:09:21 +09:00
|
|
|
subprocess.Popen(( os.path.abspath(os.path.realpath(b)),
|
2011-06-22 06:53:57 +09:00
|
|
|
'http://localhost:8080/test_slave.html?'+ qs))
|
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-19 10:09:21 +09:00
|
|
|
|
|
|
|
|
|
|
|
def check(task, results, browser):
|
|
|
|
failed = False
|
|
|
|
for r in xrange(len(results)):
|
|
|
|
pageResults = results[r]
|
|
|
|
for p in xrange(len(pageResults)):
|
|
|
|
pageResult = pageResults[p]
|
|
|
|
if pageResult is None:
|
|
|
|
continue
|
|
|
|
failure = pageResult.failure
|
|
|
|
if failure:
|
|
|
|
failed = True
|
2011-06-22 17:35:46 +09:00
|
|
|
State.numErrors += 1
|
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-19 10:09:21 +09:00
|
|
|
print 'TEST-UNEXPECTED-FAIL | test failed', task['id'], '| in', browser, '| page', p + 1, 'round', r, '|', failure
|
|
|
|
|
|
|
|
if failed:
|
|
|
|
return
|
|
|
|
|
|
|
|
kind = task['type']
|
2011-06-22 06:53:57 +09:00
|
|
|
if 'eq' == kind:
|
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-19 10:09:21 +09:00
|
|
|
checkEq(task, results, browser)
|
|
|
|
elif 'fbf' == kind:
|
|
|
|
checkFBF(task, results, browser)
|
|
|
|
elif 'load' == kind:
|
|
|
|
checkLoad(task, results, browser)
|
|
|
|
else:
|
|
|
|
assert 0 and 'Unknown test type'
|
|
|
|
|
|
|
|
|
|
|
|
def checkEq(task, results, browser):
|
2011-06-22 06:53:57 +09:00
|
|
|
pfx = os.path.join(REFDIR, sys.platform, browser, task['id'])
|
|
|
|
results = results[0]
|
2011-06-23 10:37:58 +09:00
|
|
|
taskId = task['id']
|
2011-06-22 06:53:57 +09:00
|
|
|
|
|
|
|
passed = True
|
|
|
|
for page in xrange(len(results)):
|
2011-06-22 17:35:46 +09:00
|
|
|
snapshot = results[page].snapshot
|
2011-06-22 06:53:57 +09:00
|
|
|
ref = None
|
2011-06-22 17:35:46 +09:00
|
|
|
eq = True
|
|
|
|
|
|
|
|
path = os.path.join(pfx, str(page + 1))
|
|
|
|
if not os.access(path, os.R_OK):
|
|
|
|
print 'WARNING: no reference snapshot', path
|
|
|
|
State.numEqNoSnapshot += 1
|
|
|
|
else:
|
2011-06-22 06:53:57 +09:00
|
|
|
f = open(path)
|
|
|
|
ref = f.read()
|
|
|
|
f.close()
|
|
|
|
|
2011-06-22 17:35:46 +09:00
|
|
|
eq = (ref == snapshot)
|
|
|
|
if not eq:
|
2011-06-23 10:37:58 +09:00
|
|
|
print 'TEST-UNEXPECTED-FAIL | eq', taskId, '| in', browser, '| rendering of page', page + 1, '!= reference rendering'
|
|
|
|
# XXX need to dump this always, somehow, when we have
|
|
|
|
# the reference repository
|
|
|
|
if State.masterMode:
|
|
|
|
if not State.eqLog:
|
|
|
|
State.eqLog = open(EQLOG_FILE, 'w')
|
|
|
|
eqLog = State.eqLog
|
|
|
|
|
|
|
|
# NB: this follows the format of Mozilla reftest
|
|
|
|
# output so that we can reuse its reftest-analyzer
|
|
|
|
# script
|
|
|
|
print >>eqLog, 'REFTEST TEST-UNEXPECTED-FAIL |', browser +'-'+ taskId +'-page'+ str(page + 1), '| image comparison (==)'
|
|
|
|
print >>eqLog, 'REFTEST IMAGE 1 (TEST):', snapshot
|
|
|
|
print >>eqLog, 'REFTEST IMAGE 2 (REFERENCE):', ref
|
|
|
|
|
2011-06-22 17:35:46 +09:00
|
|
|
passed = False
|
|
|
|
State.numEqFailures += 1
|
|
|
|
|
|
|
|
if State.masterMode and (ref is None or not eq):
|
|
|
|
tmpTaskDir = os.path.join(TMPDIR, sys.platform, browser, task['id'])
|
|
|
|
try:
|
|
|
|
os.makedirs(tmpTaskDir)
|
|
|
|
except OSError, e:
|
|
|
|
pass
|
|
|
|
|
|
|
|
of = open(os.path.join(tmpTaskDir, str(page + 1)), 'w')
|
|
|
|
of.write(snapshot)
|
|
|
|
of.close()
|
|
|
|
|
2011-06-22 06:53:57 +09:00
|
|
|
if passed:
|
|
|
|
print 'TEST-PASS | eq test', task['id'], '| in', browser
|
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-19 10:09:21 +09:00
|
|
|
|
|
|
|
|
|
|
|
def checkFBF(task, results, browser):
|
|
|
|
round0, round1 = results[0], results[1]
|
|
|
|
assert len(round0) == len(round1)
|
|
|
|
|
2011-06-22 06:53:57 +09:00
|
|
|
passed = True
|
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-19 10:09:21 +09:00
|
|
|
for page in xrange(len(round1)):
|
|
|
|
r0Page, r1Page = round0[page], round1[page]
|
|
|
|
if r0Page is None:
|
|
|
|
break
|
|
|
|
if r0Page.snapshot != r1Page.snapshot:
|
|
|
|
print 'TEST-UNEXPECTED-FAIL | forward-back-forward test', task['id'], '| in', browser, '| first rendering of page', page + 1, '!= second'
|
2011-06-22 06:53:57 +09:00
|
|
|
passed = False
|
2011-06-22 17:35:46 +09:00
|
|
|
State.numFBFFailures += 1
|
2011-06-22 06:53:57 +09:00
|
|
|
if passed:
|
|
|
|
print 'TEST-PASS | forward-back-forward test', task['id'], '| in', browser
|
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-19 10:09:21 +09:00
|
|
|
|
|
|
|
|
|
|
|
def checkLoad(task, results, browser):
|
|
|
|
# Load just checks for absence of failure, so if we got here the
|
|
|
|
# test has passed
|
|
|
|
print 'TEST-PASS | load test', task['id'], '| in', browser
|
|
|
|
|
|
|
|
|
2011-06-22 17:35:46 +09:00
|
|
|
def processResults():
|
|
|
|
print ''
|
|
|
|
numErrors, numEqFailures, numEqNoSnapshot, numFBFFailures = State.numErrors, State.numEqFailures, State.numEqNoSnapshot, State.numFBFFailures
|
|
|
|
numFatalFailures = (numErrors + numFBFFailures)
|
|
|
|
if 0 == numEqFailures and 0 == numFatalFailures:
|
|
|
|
print 'All tests passed.'
|
|
|
|
else:
|
|
|
|
print 'OHNOES! Some tests failed!'
|
|
|
|
if 0 < numErrors:
|
|
|
|
print ' errors:', numErrors
|
|
|
|
if 0 < numEqFailures:
|
|
|
|
print ' different ref/snapshot:', numEqFailures
|
|
|
|
if 0 < numFBFFailures:
|
|
|
|
print ' different first/second rendering:', numFBFFailures
|
|
|
|
|
|
|
|
if State.masterMode and (0 < numEqFailures or 0 < numEqNoSnapshot):
|
|
|
|
print "Some eq tests failed or didn't have snapshots."
|
|
|
|
print 'Checking to see if master references can be updated...'
|
|
|
|
if 0 < numFatalFailures:
|
|
|
|
print ' No. Some non-eq tests failed.'
|
|
|
|
else:
|
|
|
|
' Yes! The references in tmp/ can be synced with ref/.'
|
|
|
|
if not prompt('Would you like to update the master copy in ref/?'):
|
|
|
|
print ' OK, not updating.'
|
|
|
|
else:
|
|
|
|
sys.stdout.write(' Updating ... ')
|
|
|
|
|
|
|
|
# XXX unclear what to do on errors here ...
|
|
|
|
# NB: do *NOT* pass --delete to rsync. That breaks this
|
|
|
|
# entire scheme.
|
|
|
|
subprocess.check_call(( 'rsync', '-arv', 'tmp/', 'ref/' ))
|
|
|
|
|
|
|
|
print 'done'
|
|
|
|
|
|
|
|
|
2011-06-22 06:53:57 +09:00
|
|
|
def main(args):
|
2011-06-22 17:35:46 +09:00
|
|
|
masterMode = False
|
2011-06-22 17:50:43 +09:00
|
|
|
manifestFile = DEFAULT_MANIFEST_FILE
|
2011-06-22 17:35:46 +09:00
|
|
|
if len(args) == 1:
|
|
|
|
masterMode = (args[0] == '-m')
|
2011-06-22 17:50:43 +09:00
|
|
|
manifestFile = args[0] if not masterMode else manifestFile
|
2011-06-22 17:35:46 +09:00
|
|
|
|
|
|
|
setUp(manifestFile, masterMode)
|
|
|
|
|
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-19 10:09:21 +09:00
|
|
|
server = HTTPServer(('127.0.0.1', 8080), PDFTestHandler)
|
|
|
|
while not State.done:
|
|
|
|
server.handle_request()
|
|
|
|
|
2011-06-22 17:35:46 +09:00
|
|
|
processResults()
|
|
|
|
|
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-19 10:09:21 +09:00
|
|
|
if __name__ == '__main__':
|
2011-06-22 06:53:57 +09:00
|
|
|
main(sys.argv[1:])
|