leap: Updated exercise to 1.4.0 version

[ZapAnton]

This PR syncs the leap exercise with the problem-specifications repo.

It introduces the following changes:

• Adds all the cases from canonical data. The cases that were present in the suite were not present in the canonical version, so I added new cases in a test_description_in_lowercase format. The old cases were not touched (except the one that checked the 1996 year - it was present in canonical data, so I replaced it with the formatted case). Perhaps some old test cases could be deleted?

• Replaced i32 argument type with u64 - no negative years are expected, so I thought it would make sense

Relevent PR: exercism/problem-specifications#1359

[petertseng]

For this update to leap, note that there are multiple PRs that fall within the definition of "relevant PR" since this one spans multiple versions 1.0.0 through 1.4.0. I usuallly would use something like https://github.com/exercism/problem-specifications/pulls?q=is%3Apr+leap+is%3Aclosed to find them, or git log exercises/leap/canonical-data.json. In this case:

• https://github.com/exercism/problem-specifications/pull/1112 leap: Apply new "input" policy problem-specifications#1112
• https://github.com/exercism/problem-specifications/pull/971 leap: Fix loophole in unit tests problem-specifications#971
• https://github.com/exercism/problem-specifications/pull/955 leap: Improve test suite to cover corner case. problem-specifications#955

(in addition to the 1.3.0 -> 1.4.0 update you already linked)

[coriolinus]

I'm going to give this until tomorrow for discussion, then merge if no objections have arisen.

[ZapAnton]

Still not sure about the old, track-specific tests. Will they not overload the students?

[coriolinus]

In this respect my approach differs from Exercism's official policy: I personally always immediately remove all #[ignore] tags before beginning a new exercise, and write code which solves all tests simultaneously. It produces the same result as approaching the problem incrementally, while ensuring that I don't start heading down architectural routes which turn out not to work with the requirements of later tests.

In a professional context, assuming a well-managed project, coders deal with test suites comprising thousands of tests. If a dozen fail because of a change you made, you just have to deal with it. I therefore believe that we should encourage students not to be afraid of a bunch of test failures, but to embrace them: each one tells you about something your code needs to do.

To answer your question for myself, then, I'd say no, students won't be overwhelmed: correct code will pass all tests anyway; incorrect code can always use more examples of what outputs should correspond to what inputs.

To answer your question speaking ex officio as the track maintainer, I'd say that by maintaining a track policy of preferring to add tests without removing them, we are simultaneously following good project management practices and encouraging students to view tests as a bulk product for code improvement, not as individual hurdles which must be cleared.

[petertseng]

are duplicates a concern? noting that 1800 and 2000 appear in both old and new.

[coriolinus]

I'm not really worried about them. I don't object if someone wants to remove duplicate tests, but I don't think it's worth anyone's time to actually do that work. In general—and in this case in particular—the cost of any individual test in this suite is effectively zero, so there's no penalty to adding tests. There are suites and tests where that general rule does not hold, which deserve more attention. Leap is a constant-time problem, though; if I could think of a good way to do so without giving away the solution, I'd add a parametric test macro which added a test for every year between 1582 (invention of the gregorian calendar) and 3000 (far enough in the future that we don't care what's past that). That would of course mean long test reports and more duplicate tests, but the key point is that we could have lots of tests without penalty here.

…

On Tue, Nov 20, 2018 at 11:14 AM Peter Tseng ***@***.***> wrote: ***@***.**** commented on this pull request. are duplicates a concern? noting that 1800 and 2000 appear in both old and new. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#753 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHdeTqE3rDmQVm-PoJ8O8i2NFynJEuAxks5uw9YKgaJpZM4YopWA> .