luhn: update test files

[robphoenix]

Add an example_gen.go testCases generator to generate the testCases from
the x-common canonical data. Generate the new testCases data and update
the example to pass the new test data. Bump the testVersion to 2.

[robphoenix]

I realise exercism/problem-specifications#522 and exercism/problem-specifications#523 are still open and could well affect this PR, so our track should leave this unmerged until they are resolved, and any relevant updates can be made to these commits.

[petertseng]

Sure, we can look at this again when the two x-common issues are done.

The circumstance in which we would merge it now:

• We predict that neither x-common issue will require a change to the generator or example solution; we just run the generator again.
• We think there is a big advantage in getting the tests in this PR out to the students out -- they offer something the current tests don't (currently the distinction is pretty small, but you could convince me otherwise)

Alternatively if you just want to pull the "move TestTestVersion" into a separate PR we can get that merged now; it doesn't depend on having a generator.

Also, probably good to prefix the "move TestTestVersion" commit with "luhn:"

[robphoenix]

separated into 2 PRs (#480)

[robphoenix]

I've updated this to reflect the merged changes form exercism/problem-specifications#522, the example.go has changed again so do make sure you're happy with it before approving.
Still waiting on exercism/problem-specifications#523 before merging

[petertseng]

personally, I would strive to avoid the repetition of the '0' and '9', by saying continue if r == ' ', then the remaining cases are if/else of each other. Assuming I didn't get my logic wrong. Does it make sense?

[robphoenix]

that makes better sense, yes

[petertseng]

I'm assuming check returns the sum? Would anything go wrong if we just used check(d) % 10 == 0?

E: Oh never mind, this is a same line as above, just moved. I guess we don't need to change it, though if it's going to show up in git diff as a diff anyway, maybe we could consider

[robphoenix]

updated to take into account @petertseng comments. The sum function (formerly check function) is more deeply nested than I would like but I think makes things a little clearer now that the Valid function can return check(d)%10 == 0 rather than what it did before.

[petertseng]

this makes me realize there are some alternatives for how to structure this. They all have some advantage or disadvantage, so you can pick one you like after trying out:

1. Don't bother having if r == ' ' { continue } above. Instead just have else if r != ' ' { return false } here. Pro: Fewer clauses. Cons: May be a little harder to understand in what cases it does neither.

2. Invert the checks, say if r < '0' || r > '9' { return false } above. Pro: Now the d = append can be unindented. Con: Have to read through two conditions before getting to the "actual" loop body (the case that causes something interesting to happen)

3. Leave as-is. Pro: Smaller diff against current code. Con: typical-case loop body sandwiched between two other cases.

[robphoenix]

I chose door no. 2 👍

[robphoenix]

waiting for:

• luhn: Add more tests problem-specifications#522
• luhn: It's about checksums. problem-specifications#523
• luhn: tweak canonical tests problem-specifications#547
• luhn: update examples to reinforce manipulating from the right problem-specifications#549

[robphoenix]

I think we can merge this now without waiting on exercism/problem-specifications#523 to be resolved, we can update the exercise when that happens.
Unless there's any objections I think I'll merge this in the next day or so.

[petertseng]

I find it likely that exercism/problem-specifications#523 will not change the structure of the JSON file, so we can simply rerun the generator at that time, and not wait.

Of course, there is a new JSON schema, but when that gets applied it might make our lives easier since supposedly that means each exercise's JSON file will have in common, which means we can write less exercise-specific code. We will see if that bears fruit!

[robphoenix]

👍