In the “digital humanities,” we do not yet have established practices or institutions for evaluating functioning systems: we’re still better at the “humanities” than the “digital” part of our work. I take it as axiomatic that claims about automated systems need to be backed by automated forms of analysis and verification. Otherwise, journal publications or conference publications describing digital work are only remote and subjective proxies.
My work on this computational system for working with ancient Greek borrows well established practices from computer science and engineering so that others can evaluate its code libraries before investing their time in using them. For each separately packaged library, I include three complementary forms of automatically generated information.
src/test
directory of each package. The full suite of tests for each package can be run with the command gradle test
. (In the morphology
project, see the README
file for ensuring that the test data are properly loaded in the parser prior to testing.)gradle groovydoc
.gradle conc
. Statements that are verified by automated testing are highlighted in green.Release versions of each package pass 100% of its unit tests and 100% of the tests in its formal specifications, so anyone depending on a binary release can be confident of what tests it has passed. The prose specification gives a high-level overview of each package; for those who want to understand the system’s internal operation, API documentation and unit tests together give a detailed, tested description.