sync phone-number

[tomasnorre]

Solves issue #800

[github-actions]

This PR touches files which potentially affect the outcome of the tests of an exercise. This will cause all students' solutions to affected exercises to be re-tested.

If this PR does not affect the result of the test (or, for example, adds an edge case that is not worth rerunning all tests for), please add the following to the merge-commit message which will stops student's tests from re-running. Please copy-paste to avoid typos.

[no important files changed]

For more information, refer to the documentation. If you are unsure whether to add the message or not, please ping @exercism/maintainers-admin in a comment. Thank you!

[tomasnorre]

Long time no see. I have started this PR. But would like some feedback if I have understood the tasks correctly.

I have done following:
Ran bin/configlet sync -u -e phone-number --yes --docs --filepaths --metadata --tests include
Added uuid to test cases
Remove strict types comment in example code and tests file.

Testcases with uuid: 2de74156-f646-42b5-8638-0ef1d8b58bc2 and 4a1509b7-8953-4eec-981b-c483358ff531 are not implemented, as they would break current community solutions. So how to deal with those?

I don't see which 4 tests cases that aren't implemented according to https://github.com/exercism/problem-specifications/blob/main/exercises/phone-number/canonical-data.json .
A pointer would be nice.

[mk-mxp]

Hi Tomas,

nice to see you contributing again.

---

Please don't use @uuid: (it is not a valid annotation), use uuid or uuid: only. Also add the test case description to the DocBlock with a @testdox annotation for the online editor feedback:

    /**
     * uuid 79666dce-e0f1-46de-95a1-563802913c35
     * @testdox Cleans the number
     */

---

I don't see which 4 tests cases that aren't implemented according to https://github.com/exercism/problem-specifications/blob/main/exercises/phone-number/canonical-data.json .
A pointer would be nice.

The phone-number: missing 4 test cases was output by configlet and can mean many things. Looking at tests.toml I'd say, the replacement of 4 tests has happened, and those need to be changed in our test file (if that doesn't break existing solutions).

[598d8432-0659-4019-a78b-1c6a73691d21]
description = "invalid when 9 digits"
include = false

[2de74156-f646-42b5-8638-0ef1d8b58bc2]
description = "invalid when 9 digits"
reimplements = "598d8432-0659-4019-a78b-1c6a73691d21"

This means, UUID 598d8432-0659-4019-a78b-1c6a73691d21 is no longer to use (include = false) and UUID 2de74156-f646-42b5-8638-0ef1d8b58bc2 replaces it (reimplements = "598d8432-0659-4019-a78b-1c6a73691d21").

---

Testcases with uuid: 2de74156-f646-42b5-8638-0ef1d8b58bc2 and 4a1509b7-8953-4eec-981b-c483358ff531 are not implemented, as they would break current community solutions. So how to deal with those?

Please describe: Why are those test cases breaking solutions? Did some rule change? Or did some untested edge-case slip through? How many solutions exist (see track build status -> Practice Exercises -> active practice exercises -> column "completions")? How many of the first page of the community solutions would break?

[tomasnorre]

Hi Tomas,

nice to see you contributing again.

Thanks. Happy to be back.

Please don't use @uuid: (it is not a valid annotation), use uuid or uuid: only. Also add the test case description to the DocBlock with a @testdox annotation for the online editor feedback:

    /**
     * uuid 79666dce-e0f1-46de-95a1-563802913c35
     * @testdox Cleans the number
     */

Done.

I don't see which 4 tests cases that aren't implemented according to https://github.com/exercism/problem-specifications/blob/main/exercises/phone-number/canonical-data.json .
A pointer would be nice.

The phone-number: missing 4 test cases was output by configlet and can mean many things. Looking at tests.toml I'd say, the replacement of 4 tests has happened, and those need to be changed in our test file (if that doesn't break existing solutions).

[598d8432-0659-4019-a78b-1c6a73691d21]
description = "invalid when 9 digits"
include = false

[2de74156-f646-42b5-8638-0ef1d8b58bc2]
description = "invalid when 9 digits"
reimplements = "598d8432-0659-4019-a78b-1c6a73691d21"

This means, UUID 598d8432-0659-4019-a78b-1c6a73691d21 is no longer to use (include = false) and UUID 2de74156-f646-42b5-8638-0ef1d8b58bc2 replaces it (reimplements = "598d8432-0659-4019-a78b-1c6a73691d21").

This is the output from the configlet now, so looks to me that it's up to date.

The `phone-number` exercise has up-to-date docs, filepaths, metadata, and tests!

Testcases with uuid: 2de74156-f646-42b5-8638-0ef1d8b58bc2 and 4a1509b7-8953-4eec-981b-c483358ff531 are not implemented, as they would break current community solutions. So how to deal with those?

Please describe: Why are those test cases breaking solutions? Did some rule change? Or did some untested edge-case slip through? How many solutions exist (see track build status -> Practice Exercises -> active practice exercises -> column "completions")? How many of the first page of the community solutions would break?

There expected error messages has change, from "incorrect number of digits" to "must not be fewer than 10 digits" and as we are checking for

$this->expectExceptionMessage('incorrect number of digits');

Therefor the tests will break. The same goes for the other test case, not updated. It's just different wordings.

181 persons have completed that exercise. To my knowledge all will break if changing the wording in the exception messages.

[mk-mxp]

Thank you for adjusting the DocBlocks. Don't forget to un-draft the PR, so it can be merged.

For compatibility remove testing for the exception message or use expectExceptionMessageMatches() with a RegExp that can handle both texts. I'd prefer not testing for the message.

[tomasnorre]

For compatibility remove testing for the exception message or use expectExceptionMessageMatches() with a RegExp that can handle both texts. I'd prefer not testing for the message.

Will do one of the next days. Don't have time right now. But will take care asap.

[mk-mxp]

Thanks for your work! I think expectExceptionMessageMatches() needs the RegExp to be surrounded by limiters (e.g. /.* than 11 digits/). But I always have to try that out myself 😃