Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Module tests #55

Open
fbennett opened this issue Mar 18, 2015 · 2 comments
Open

Module tests #55

fbennett opened this issue Mar 18, 2015 · 2 comments

Comments

@fbennett
Copy link
Contributor

[from decommissioned csl-validator.js fork]

Modules should be associated with integration test fixtures, so that their behavior can be easily illustrated, and confirmed during review. For Zotero translators, tests are embedded in the translators themselves; a similar approach can be adopted in Juris-M style modules.

We would start with comprehensive sample text for each Juris-M item type. In casting a test, the module author would select the fields to be included in the test fixture. When approved, a record of the fields to be used and the (XML-escaped) expected output would be added to the module, and travel with it.

@fbennett
Copy link
Contributor Author

With a standard set of variable values, the fields to be included in a test fixture can be expressed concisely as a parameter string, accompanied by the current style output and a flag to show if it's passing or failing on human review. Something like:

<tests>
   <test parameters="310410010200101001">Smith et al., "On Time and Place," 1977</test>
</tests>

The standard field data will need to be rigidly organized. It can be documented in reST, and a custom renderer can dump the JS needed for the test platform. The text of the reST can be pegged at a version increment, so that a style pulls the correct data for its level.

@cormacrelf
Copy link

cormacrelf commented Nov 23, 2018

Hey Frank. I wrote one, https://github.com/cormacrelf/jest-csl/. I didn't see this issue, but now that I have, I wouldn't say all that configuration complexity is necessary. The duality of tests as specifications/documentation as well as being tests is not well served by using a rigid set of standard variable values. Instead, slamming any test input into citeproc-js is fine, and since you can put anything in there, you can use recognizable examples and carry it through to generated documentation for using the CSL under test.

(Aside: I actually came here searching for how you produce the field mappings in the Style Development editor. There's that weird custom-compressed src/fields.json (GZIP would probably do a better job than numeric back-references, but OK), but how did you produce that? Is that the canonical copy? Is there one for plain Zotero? I'm trying write a CSL-JSON -> tutorial for how to enter this item in your reference manager } function.)

Here's a sneak preview of the generated, interactive documentation based on the test suite I'm currently writing (and yes, there is a bug in my getAbbreviation implementation):

screen shot 2018-11-24 at 02 12 56

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants