Sync connect

[mk-mxp]

• Run bin/configlet sync -u -e connect --yes --docs --filepaths --metadata --tests include (updates the Markdown files and maybe tests.toml)
  • docs: instructions unsynced: connect
  • metadata: unsynced: connect
• Drop strict types comments from test file and example code (these are useless)
• Add and sync test meta data to tests (uuid / @testdox in DocBlocks)
• Decide on adding / adjusting / ordering test cases to match current problem specs

Do not redesign the student's interface or add test cases that would invalidate existing community solutions. These are extra tasks, which should be discussed in advance.

[mk-mxp]

There is a couple of decisions to make:

1. Canonical data asks for winner property, we have resultFor
2. Canonical data has "diagonal strings", we remove the spaces before invoking the solution (taking away one step of processing from the students side)
3. The current tests use @depends to hide unsolved tests from students, until they solved the current test. This is much more "test driven development" as all the other exercises

1. resultFor or winner?

When syncing other exercises, we chose to invalidate existing solutions in favor of strict following canonical data. As we have only 183 attempts and 83 solutions, I think we should use winner and break things.

2. "diagonal strings" or "remove the spaces"

The instructions are hard to understand. It is unclear, which player has started (it doesn't matter, I know, but that's unknown at first) or which are "their sides" (yes, also doesn't matter). Taking away the "diagonal look" by pre-processing the canonical data makes the problem even more hard to understand, because the input is not the same as I can see in the tests or as the instructions show me or as I would want to have to reason about the problem.

Understanding the rules while looking at the actual input is a basic capability for programming test-first style. So I think it shouldn't be like this. Especially as we have less than 50% of students getting the exercise solved (183 attempts vs. 83 solutions).

3. @depends

During a forum discussion it was stated, that the order of tests in canonical data is meant to be the order to pass the tests. It might be helpful to then also hide all other (unsolved) tests from the students. @depends does both, order and hiding.

But we do not use @depends in any other exercise, as it means additional work to adding / synchronising exercises. Here some test methods need to be re-named to match canonical data descriptions and by that @depends annotations become invalid / must be re-evaluated and fixed.

Also there are some comments in the forum, that "suddenly new requirements appeared after solving the tasks at hand". So feeling like having won turns into a harsh rejection because of unknown, additional constraints. While this is "like real programming for money", it is discouraging for students. Maybe a lot of the unfinished attempts where caused by this surprise of hidden requirements.

So, while I think consequently presenting one test at a time would be much better TDD, we should not use this feature "randomly" in a few exercises. Maybe one day we can have a TDD introduction like Python track has one and adjust our (hopefully at that time generated) tests to using @depends from then on.

Wrap-up

I'm open for discussion. I currently prefer:

1. Use winner
2. Use "diagonal strings" as input
3. Remove @depends

@homersimpsons @tomasnorre

[homersimpsons]

I'm not familiare with this exercise but your suggestions looks right to me @mk-mxp.

About the usage of winner, I believe we can display this to the user so the ones who submitted a solution can easily update this part.

For the @depends I do not know what is best. I would hope students will try to solve the first failing test case first, but they may be overwelmed with the number of failures or attempt to fix a more difficult test case. I'm okay to remove it to stay consistent and to possibly use the concept of tasks to guide the student better though.

[mk-mxp]

@tomasnorre OK, let's have my prefered version then:

1. Use winner as the solution functions name
2. Use "diagonal strings" as input (and remove makeBoard from the tests completely)
3. Remove @depends