simple-cipher: Add canonical data #966

aos · 2017-10-21T04:47:35Z

Closes #586

Hello. I've been working on this one. There are a few places where I wasn't sure what to do, specifically L27, and others where you have to do multiple encode into decodes. Or when adding a new cipher key. Let me know what you think!

ilya-khadykin · 2017-10-21T07:24:52Z

@aos build failed due to:

exercises/simple-cipher/canonical-data.json invalid
[ { keyword: 'oneOf',
 dataPath: '.cases[0]',
 schemaPath: '#/oneOf',
 params: {},
 message: 'should match exactly one schema in oneOf' } ]

Insti · 2017-10-21T09:45:25Z

Link to problem description: https://github.com/exercism/problem-specifications/blob/master/exercises/simple-cipher/description.md

Insti · 2017-10-31T09:15:08Z

Hi @aos have you had a chance to look into why the json file is not valid?

aos · 2017-10-31T16:14:47Z

Hey @Insti. I looked at it briefly but couldn't understand. Sorry I have been very busy with work. I will look at it more tonight when I get a chance!

Insti · 2017-10-31T16:50:33Z

Try pasting the json into a schema checker for some clues:

https://jsonschemalint.com/#/version/draft-04/markup/json?gist=ba6a1e74397ade6bdbff65a9df0d9d3f

aos · 2017-10-31T17:49:15Z

Oh... that's handy. I'll look through it in a bit. Thank you!

ErikSchierboom · 2017-11-14T08:06:01Z

@aos Did you find any time to look at the problem? Do you perhaps need any help?

aos · 2017-11-14T14:46:26Z

@ErikSchierboom @Insti Hey finally got around to it. The latest commit fixes the schema validation issue. Let me know what still needs work -- I'll eventually squash these into a single commit

coriolinus

I see all of input, input_plaintext, input_string, input_encode, input_all_caps_string, input_all_numbers_string, and possibly others in the cases. I also see output_key, matches_regex, output_string, output_decode, and output_error; there are again possibly others that I've missed.

I haven't gone through to check that all items with the same property have the same inputs and outputs; if they do, that's technically not wrong. Still, it's both better aesthetics and easier to automatically generate tests with if every test case has the same schema:

{
   "property": "Some string",
   "description": "Text describing what this case is checking",
   "input": "any literal",
   "expected": {
      "value": "success value (any type)"
// or "error": "error type"
// or "matches_regex": "regex"
   }
}

In the above example, you can assign whatever attributes you like to the expected object, as is appropriate for the test case; as long as every test of the same property has the same object attributes, things work out well. Likewise, you can set the input to whatever you like, as long as the types are consistent within a given property. The key is consistency.

coriolinus · 2017-11-14T16:11:02Z

you can assign whatever attributes you like to the expected object

cf. the Readme:

There are also some convention about expected that you must follow:

if the input is valid but there is no result for the input, the value at "expected" should be null.

if an error is expected (because the input is invalid, or any other reason), the value at "expected" should be an object containing exactly one property, "error", whose value is a string.

The string should explain why the error would occur.

A particular track's implementation of the exercise need not necessarily check that the error includes that exact string as the cause, depending on what is idiomatic in the language (it may not be idiomatic to check strings for error messages).

ErikSchierboom

I've added some remarks. Don't be daunted, most of it is relatively simple and involves being consistent with other exercises. It might help to look at some other exercises like https://github.com/exercism/problem-specifications/blob/master/exercises/atbash-cipher/canonical-data.json.

Thanks a lot for working on this!

ErikSchierboom · 2017-11-14T17:11:20Z