Use the type testing functions

[mikegehard]

This is more explicit about what the expectation is.

[github-actions[bot]]

Thank you for contributing to exercism/elixir 💜 🎉. This is an automated PR comment 🤖 for the maintainers of this repository that helps with the PR review process. You can safely ignore it and wait for a maintainer to review your changes.

Based on the files changed in this PR, it would be good to pay attention to the following details when reviewing the PR:

• General steps

  • 🏆 Does this PR need to receive a label with a reputation modifier (x:size/{tiny,small,medium,large,massive})? (A medium reputation amount is awarded by default, see docs)

• Any exercise changed

  • 👤 Does the author of the PR need to be added as an author or contributor in <exercise>/.meta/config.json (see docs)?
  • 🔬 Do the analyzer and the analyzer comments exist for this exercise? Do they need to be changed?
  • 📜 Does the design file (<exercise>/.meta/design.md) need to be updated to document new implementation decisions?

• Concept exercise changed

  • 🌲 Do prerequisites and practices in config.json need to be updated?
  • 📖 Does the concept introduction provide all necessary information to solve this exercise?

• Concept exercise tests changed

  • ⚪️ Are all tests un-skipped?
  • 🔢 Are all tests annotated with @tag task_id?
  • 🐈 Can all tests be understood by reading the test's block only (e.g. no module attributes, no setup functions)?

---

Automated comment created by PR Commenter 🤖.

[github-actions[bot]]

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!

[angelikatyborska]

Thank you for the suggestion, but I disagree with the change. I think the change makes the test output in case of a failure less understandable, and it also removes the extra check of what the actual value is.

Before your changes, a failed test shows the expected number and the returned number line by line, with a highlighted .0, making the difference very clear. You can see immediately that your implementation returned an integer and not a float.

After your changes, a failed test's highlighted part says "expected true, got false", which is a bit unclear for a function that returns a number, not a boolean. You have to read the whole test to notice that it calls is_float. Additionally, this failure doesn't tell you at all what is the type of the value that you returned. It only tells you that you didn't return a float.

For this reason, I have to reject this PR.

[mikegehard]

Thanks for the feedback. Is there any room for a discussion on the pros/cons of each approach or is this decision final?

[angelikatyborska]

I consider this to be a very minor issue and would rather not spend more of my time on it, but if you have more thoughts on the topic, you can share them.

[mikegehard]

Gotcha. I don't want to take up more of your time.