Add additional test to exercise "dominoes"


One of my students had a solution that did pass all the tests, but had a logic error. So I found this additional test, that would not pass:

[1, 2], [4, 4], [2, 2], [2, 3], [3, 4], [4, 1], [1, 1], [3, 3]

how could I add this?

1 Like

New tests typically go in the problem specs repo via a PR. New tests like these should include a brief comment explaining why this test is unique and different from all the other tests and why it adds value which isn’t covered by the other tests. This forum topic might be a good place to try and flesh out those whys via a discussion.

What was the logic error? Why does the student’s logic pass all the other tests? What is special about this test, such that is adds value above and beyond all the existing tests?

1 Like

I thought PRs get all closed immediately.

So my student die not backtrack correctly and instead did try to use every domino as start domino. This in combination with some weird double loop search for finding the next matching domino resulted in passing all test.

Depends on the repo. But that doesn’t preclude repo teams from reopening PRs which they discussed and requested.

Can you describe the incorrect logic which this test captures. “not […] correctly” and “weird […] search” does not describe the issue. It indicates that it is possible to solve the exercise in a manner where the other tests pass and this one does not. It does not describe the approach or nor what is different about this particular test. Without a concrete and specific explanation about why this test adds value, it is really hard to judge whether there’s any value in adding this additional test.


Can you summarize the problematic algorithm or the problem with it? If you can’t … is it worth testing for a problem that cannot be explained?

It’s trivial for students to write solutions which works for the given tests but failed any other tests. They can just hard code all the inputs and expected outputs. The tests aren’t there to somehow catch every conceivable bug or too-tuned solution. The tests are meant to provide good (enough) coverage to ensure more solutions would work for most inputs. It’s extremely difficult to write tests that can cover every possible solution and capture every possible bug.