In Firefox 102, `-file` was being swallowed by `nsBrowserContentHandler`
in BrowserContentHandler.jsm, so ab7d916e0 overrode that by using the
same contract id for our main nsICommandLineHandler in
zotero-service.js. But `nsBrowserContentHandler` also handles `-chrome`,
which we were using in tests to pass runtests.html. There's no need to
pass in dynamically though -- we can just hard-code that and open the
window ourselves.
- Make a copy of the database after first initialization that can be
swapped in when reinitializing in resetDB()
- Avoid unnecessary one-second delay on every reset
Probably more that can be done, but this should take minutes off the
test runs
This expands the test filtering in the test runner so that you can supply e.g.
`test/tests/feed*` from your shell in the `zotero` directory and correctly
filter to all feed-related tests.
I'm not sure what this was for, but at least with an async test function
it seems to be causing spurious "the string 'x' was thrown, throw an
Error :)" messages that hide the real error.
This is useful when trying to debug an error that only happens after a
number of other tests have run -- specify -e and run tests from either
an earlier file with -s or from the beginning.
And don't skip alerts in Zotero.alert() during automated tests. (That
was intended to avoid long timeouts after unexpected failures, but,
e.g., PDF metadata lookups (which are currently disabled in automated
tests) should just be mocked so they don't intermittently fail.)
The test runner now downloads and caches the PDF tools for the current
platform within the test data directory and only redownloads them when
out of date, and it updates the download URL so that the full-text code
pulls from the cache directory via a file:// URL.
The installPDFTools() support function now installs the files directly
instead of going through the prefs, and a new uninstallPDFTools()
function removes the tools. Since the presence of the PDF tools can
affect other tests, tests that need the tools should install them in a
before() and uninstall them in an after(), leaving most tests to run
without PDF indexing.
This also adds a callback to the waitForWindow() support function. If a
modal dialog is opened, it blocks the next promise handler from running,
so a callback has to be used to interact with and close the dialog
immediately.
(Mocha has a 'bail' config flag that's supposed to do this, but it doesn't seem
to work when passed to mocha.setup() (maybe because we're setting a custom fail
handler?), so this just calls abort() on the runner manually.)
This is arbitrary, and we could increase it more or make it configurable via
the command line if Travis continue to time out, but this allows all tests to
complete for me in a VM.
Not crazy about this, but (at least on my system) it's an easy way to
avoid DB errors due to interrupted transaction or query errors after the
DB connection was cleaned up. (I can reproduce those pretty reliably
right now by running collectionTreeView tests alone.)
Add functions to generate sample data for various formats
* Zotero Web API JSON (Zotero.Item::toJSON)
* CiteProc-JS JSON
* Export translator JSON
* Direct serialization of Zotero.Item fields
Add a way to load sample data into DB from JSON
Add tests for loading sample data into DB
Add tests for automatically generated data
This will help us make sure that field mappings and data formats don't change
