Select language for development of Fedora API test suite

fcrepo / fcrepo-specification

Fedora API Specification

Apache License 2.0

17 stars 15 forks source link

Select language for development of Fedora API test suite #159

Closed zimeon closed 7 years ago

zimeon commented 7 years ago

We plan to have a test suite or Technology Compatibility Kits for Fedora API Specification to verify compliance with the Fedora API specification. This will involve tests in addition to those in the LDP Test Suite but may also replicate some (or all) of the LDP tests. What language should the test suite be written in. Considerations include:

Ease of use of the test suite in one-off and CI situations
Ease of test suite development
Impact on community participation in development and maintenance

awoods commented 7 years ago

Two top contenders that have been mentioned are Python and Java.

Python has been raised as an option with the assumption that it supports bullet-3, above. Java already has an LDP suite and experienced contractors to move on this immediately.

escowles commented 7 years ago

I am fine with any language that's widely used, such as Python and Java mentioned above, and also Ruby, Javascript, PHP, etc.

Having contractors available to implement a TCK quickly is a plus, but not worth picking a language that will hinder the long-term community participation (and hence sustainability).

awoods commented 7 years ago

That is a good point, @escowles

[not] picking a language that will hinder the long-term community participation (and hence sustainability).

Do you have a sense of which language(s) would be suitable for this sort of community participation and sustainability?

escowles commented 7 years ago

@awoods I don't have any new information here — I've seen Java and Python used for Fedora projects, and Ruby used in Samvera ones. I would say there are many more Samvera contributors, but I'm not sure how much of a factor the language is, as opposed to frontend/backend considerations for feature development.

birkland commented 7 years ago

Here's a small data point from my personal perspective:

As someone who will be working on updating the community impl, it would be ideal if the test suite could be run as part of ITs in the Maven lifecycle.
I'd not want to install anything specific to the test suite (except for standard runtime environments such as a JVM, python interpreter, etc). If running the suite manually, downloading a self-contained artifact containing the tests (a script, executable jar file, cloning a git repo and running tests from the command line) is preferable.
Unless the existing LDP test suite is going to be replaced/rewritten, it'd seem less cumbersome to use the same technology and patterns as the existing suite.

dannylamb commented 7 years ago

I think having contractors ready to go on Java is important, otherwise, we need to consider the effort to find equally qualified contractors in another language. Between that and not rewriting the LDP test-suite, I'm leaning in the Java direction.

If we were to pick an arbitrary language, I think Javascript is the best choice because it breaks the language barrier. Almost everyone ends up using the language of their choice AND javascript to build web apps. So we've got a much higher chance of folks knowing it. As long as we can easily make it spit out an ERL report, that is.

awoods commented 7 years ago

In order to move this forward without taxing our existing pool of developers, a contract is underway for the development of this work in Java.