Implemented all "Phone Number" problems from the canonical test data. (#465)

[borderite]

I have revised the phone-number-test.el to include all problems from the canonical test data and correct the three track-specific problems.

[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!

[BNAndras]

I think we should check for a particular error type rather than a specific message. The expected error messages in problem-specs repo tests get updated from time to time. If the updated message still makes sense with our error type, we don't need to update the test cases then.

[borderite]

@BNAndras Given that the canonical test data contains so many different kinds of errors with distinct error messages, I think that the creator of the problem tries to have students clearly distinguish all types of errors in phone numbers. If it is the case, it is not enough to let students signal a generic error. One way to force them to distinguish all types of errors is to require specific error messages, as I did. Alternatively, we could have students define various errors with pre-specified names in phone-number.el and check if the right one is used in the tests. Is this what you have in mind?

[fapdash]

We currently have both type of tests / expected implementations in the track:

• Checking for error message:

  emacs-lisp/exercises/practice/perfect-numbers/perfect-numbers-test.el

  Lines 46 to 57 in 906e325

  	;;; Invalid Inputs
  	(ert-deftest zero-is-rejected ()
  	(should
  	(equal
  	(should-error (classify 0))
  	'(error . ("Classification is only possible for natural numbers")))))
  	(ert-deftest negative-integer-is-rejected ()
  	(should
  	(equal
  	(should-error (classify -1))
  	'(error . ("Classification is only possible for natural numbers")))))

• Checking for error type:

  emacs-lisp/exercises/practice/two-bucket/two-bucket-test.el

  Lines 54 to 58 in 906e325

  	(ert-deftest not-possible-to-reach-the-goal ()
  	;; Function under test: measure
  	;; Input: {"bucketOne":6,"bucketTwo":15,"goal":5,"startBucket":"one"}
  	;; Expected: {"error":"impossible"}
  	(should-error (measure 6 15 5 'one) :type 'goal-not-possible))

I think both approaches are fine. It's way more common to signal a default error with a custom message in Emacs Lisp than it is to define a custom error type.

Stats from my Emacs configuration with 331 packages installed:

Defining custom error:

~/.emacs.d/elpa$ rg -q --stats define-error | head -n 2 | cut -d\  -f1

54

Signaling custom errors:

$ rg -q --stats "\(signal " | head -n 2 | cut -d\  -f1

253

Signaling default error:

~/.emacs.d/elpa$ rg -q --stats "\(error " | head -n 2 | cut -d\  -f1

2076

[borderite]

@fapdash Thank you veru much for the detailed information. I think that I will go with the custom error signaling approach for the reason I mentioned earlier.

[fapdash]

You moved the exercise to the end of the JSON array. This will place it at the bottom of the https://exercism.org/tracks/emacs-lisp/exercises/ page. Was this your intention?

[BNAndras]

Does the generator use configlet --create? That defaults to a difficulty of 1 if not set and puts the exercise at the end of the practice exercise array. There shouldn't be any changes to the track config for what we want done.

[fapdash]

Why did you lower the difficulty of the exercise? Maybe the the difficulty with the new tests and requirements might be even higher than 2? You know this the best, since you implemented the new example implementation.

[borderite]

@fapdash I myself did not intentionally lower the difficulty. I followed your direction about creation of new tests, and then changed back the uuid per @BNAndras's suggestion. Anyway, I think that the difficulty of the revised problem is not much different from the original one, except that the revised one is now consistent with the problem setup.

[borderite]

I've changed the difficulty from 1 to 2.

[borderite]

I've moved the entry of "Phone Number" to the original position in ./config.json, because I am not sure what is the right order of the exercises.