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
Also some support code that was useful here and will probably be
useful for other tests. This is a pretty complicated thing to test, but
it seems to work.
Implements the beginnings of unit testing infrastructure using
mocha/chai. The unit tests can be run locally using test/runtests.sh,
although this will need tweaks to run on Windows. They should also run
on commit using Travis-CI.
The unit tests themselves live in test/tests. The index.js file
specifies separate test sets, which can be run individually by calling
test/runtests.sh <testsets>. Right now there is only a single unit
test, but hopefully we'll have more soon...
