allTypesAndFields: Direct serialization of all valid fields for all valid item types
citeProcJSExport: All item types and fields as sent to citeproc-js
itemJSON: Zotero.Item::toJSON serialization of all item types and fields
translatorExport: items as presented to export translators after 4.0.27
translatorExportLegacy: items as presented to export translators before 4.0.27
(does not cover relations, collections, tags, attachments)
citeproc-js relies on this in several locations. Seems that Zotero passes these IDs to citeproc from the item picker. We also need to consider existing embedded items in Word/LO documents, but they do have embedded URIs, so it shouldn't be a problem.
CC @fbennett
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
* Enable legacy mode for export translators compatible with pre-4.0.27:
* Add compatibility mappings, so that current translators don't break if they specify minVersion lower than 4.0.27. This does introduce non-compatible changes, specifically, "version" field in legacy mode is "versionNumber" in the new format. "version" in the new format corresponds to the "version" as specified for Zotero API JSON format. New translators should expect Zotero web API JSON format and should specify minVersion 4.0.27.
* Update CSL mappings to comply with new itemToExportFormat
* CSL JSON export translator needs to be updated to be compatible with 4.0.27 to export correct CSL JSON
* Use item URI for id in CSL JSON instead of item ID
* Fix note and attachment handling in itemToCSLJSON
Don't echo version on Windows, because it hangs Firefox
Also add testing with Firefox Beta (and prior ESR, but commented out for now, since we don't support it and we know it breaks)
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...
