After looking through the discussion about the new canonical-data.json format and what each property means I still have some thing I don't understand, I hope that somebody is willing to clarify that for me.
{
"exercise": "nucleotide-count",
"version": "1.2.0",
"cases": [
{
"description": "count all nucleotides in a strand",
"cases": [
{
"description": "empty strand",
"property": "nucleotideCounts",
"strand": "",
"expected": {
"A": 0,
"C": 0,
"G": 0,
"T": 0
}
}
]
What is property referring to, my understanding is that is the method where the exercise solution is supposed to be?
Ex (Ruby):
Implementation
def nucleotideCounts(string)
# Implementation here
end
Test
def test_empty_dna_strand_has_no_adenosine
assert_equal 0, nucleotideCounts('A')
end
If my understanding is correct I have a few follow up questions.
property is the name of the method/function/"thing" to be tested. To me, your understanding appears correct.
The few follow-up questions I have:
How important is this property, should we enforce it even if it's not necessary needed? For example in bash there are a few scripts that are better off being in a single file than in a function, and having the tests without a required function, the user can choose to do whatever he wants.
Are we required to follow the camel case notation in all tracks, ex: ruby will be better off with snake case to follow the popular style guides.
Should we be concerned to update existing exercises to follow the existing conventions discussed in 1 and 2?
You do not need to follow the property as named in the specs, but I'd recommend it. By having the same name through all tracks we make it easier for polyglots to redo an exercise in another language, also it's easier to reason about implementations as maintainers.
The name should be changed to follow the languages idioms and possibly syntax (hypothetically we could have languages which require names in all caps).
But how ever you name your stuff if you not follow the property, please make sure that cases in the canonical data refering to the same property are using the same name in your implementation. Also make sure that different property names in the data should map to different things under test in your implementation.
Thank you for your clarifications.
Most helpful comment
You do not need to follow the property as named in the specs, but I'd recommend it. By having the same name through all tracks we make it easier for polyglots to redo an exercise in another language, also it's easier to reason about implementations as maintainers.
The name should be changed to follow the languages idioms and possibly syntax (hypothetically we could have languages which require names in all caps).
But how ever you name your stuff if you not follow the property, please make sure that cases in the canonical data refering to the same property are using the same name in your implementation. Also make sure that different property names in the data should map to different things under test in your implementation.