pdfjs-dist

Tree: a1440b8e15

Author	SHA1	Message	Date
Rob Sayre	a1440b8e15	Run browsers in parallel. No limit on the number of concurrent browsers right now.	14 years ago
Rob Sayre	ebb75998a2	only supply a -foreground argument on Mac.	14 years ago
Rob Sayre	d19a6ef983	Add sample manifests. Also make a browser path argument, so you can just specify one browser without messing with a manifest.	14 years ago
Rob Sayre	ed574cb6c0	Add SpecialPowers extension to allow the browser to quit from content, and a bunch of other exciting things.	14 years ago
Rob Sayre	984c4d4de6	Add a user.js file Firefox profile. Change HTTP server to run on background thread.	14 years ago
Rob Sayre	2793532599	Modify paths of web resources to work with test resources more buried.	14 years ago
Rob Sayre	2454354b59	Move some files around.	14 years ago
Chris Jones	1532e86dcb	fix bug in testing multiple browsers	14 years ago
Chris Jones	57e7e798a6	fix strict-mode violations in chrome	14 years ago
Chris Jones	2ad4889868	remove debugging code	14 years ago
Chris Jones	4ae16721fa	actually wait for fonts to be loaded, and write out a log of failed eq comparisons	14 years ago
Rob Sayre	aa21228448	remove some accidental print statements.	14 years ago
Rob Sayre	a27771ebaa	Change test.py to use an external browser_manifest.json file, and use OptionParser to handle the command line.	14 years ago
Chris Jones	5dc5455959	deal with apparent lack of FontDescriptor for standard fonts	14 years ago
Chris Jones	7f582fb322	add support for test "master mode" and finish impl of eq tests	14 years ago
Chris Jones	f151a8d630	don't let getPage() errors break the test slave	14 years ago
Chris Jones	375c4bf529	add support for linking pdfs we can't/won't distribute	14 years ago
Chris Jones	2dff6d818c	test-harness improvements	14 years ago
Chris Jones	f7aa149778	Initial import of first test harness The harness (test.py) operates as follows. First it locates executable browsers (or symlinks or scripts) named "[browser][version]", e.g. "firefox4". It then launches the located browsers and asks them to load the file test_slave.html. At the same time, test.py sets up an HTTP server on localhost:8080 (there's a race condition here currently ;). After test_slave loads in the browser(s), it fetches the task manifest (test_manifest.json). The entries in the manifest specify which PDF to load and how many times to cycle through page rendering. This will probably evolve over time. test_slave then performs the requested tasks and POSTs the results back to test.py, which saves them. When all the results of for a task are in, test.py checks them. There are three types of tests currently. "==" tests compare the rendering of a PDF against a master copy. This is not yet implemented because setting up a master copy is complicated. "fbf" tests render all a PDF's pages, then go back to page 1 and render all pages a second time. The renderings from the first round must match the ones from the second round. "load" tests just check that a PDF's pages load without errors. Currently the test harness will only launch a "firefox4" target. This can be a bash script in your pdf.js checkout, pdf.js/firefox4, something like the following #!/bin/bash dist="/path/to/firefox4/installation" profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'` $dist/firefox -no-remote -profile $profile $* rm -rf $profile (Yes, this script doesn't clean up properly on early termination.) It's possible to run the tests in a normal browsing session, but that might be annoying. With that set up, run the harness like so python test.py If all goes well, you'll see all "TEST-PASS" messages printed to stdout. If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL" printed to stdout.	14 years ago

8 Commits (a1440b8e15bc8d2d79db8b644b3398bdb6c062a8)