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

Clarification for canonical-data.json #1070

Closed
budmc29 opened this Issue Jan 4, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@budmc29
Member

budmc29 commented Jan 4, 2018

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.

@rpottsoh

This comment has been minimized.

Show comment
Hide comment
@rpottsoh

rpottsoh Jan 4, 2018

Member

property is the name of the method/function/"thing" to be tested. To me, your understanding appears correct.

Member

rpottsoh commented Jan 4, 2018

property is the name of the method/function/"thing" to be tested. To me, your understanding appears correct.

@budmc29

This comment has been minimized.

Show comment
Hide comment
@budmc29

budmc29 Jan 4, 2018

Member

The few follow-up questions I have:

  1. 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.

  2. 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.

  3. Should we be concerned to update existing exercises to follow the existing conventions discussed in 1 and 2?

Member

budmc29 commented Jan 4, 2018

The few follow-up questions I have:

  1. 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.

  2. 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.

  3. Should we be concerned to update existing exercises to follow the existing conventions discussed in 1 and 2?

@NobbZ

This comment has been minimized.

Show comment
Hide comment
@NobbZ

NobbZ Jan 4, 2018

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.

NobbZ commented Jan 4, 2018

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.

@budmc29

This comment has been minimized.

Show comment
Hide comment
@budmc29

budmc29 Jan 7, 2018

Member

Thank you for your clarifications.

Member

budmc29 commented Jan 7, 2018

Thank you for your clarifications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment