pdf.js/test.py

322 lines
10 KiB
Python
Raw Normal View History

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
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'
EQLOG_FILE = 'eq.log'
2011-06-22 06:53:57 +09:00
REFDIR = 'ref'
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
masterMode = False
numErrors = 0
numEqFailures = 0
numEqNoSnapshot = 0
numFBFFailures = 0
numLoadFailures = 0
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)
# 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)
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 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')
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
( '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()
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
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]
taskId = task['id']
2011-06-22 06:53:57 +09:00
passed = True
for page in xrange(len(results)):
snapshot = results[page].snapshot
2011-06-22 06:53:57 +09:00
ref = None
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()
eq = (ref == snapshot)
if not eq:
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
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
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
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):
masterMode = False
manifestFile = DEFAULT_MANIFEST_FILE
if len(args) == 1:
masterMode = (args[0] == '-m')
manifestFile = args[0] if not masterMode else manifestFile
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()
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:])