Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tree Building: Tests accept tree in any order #2215

Closed
wants to merge 1 commit into from

Conversation

dirkkul
Copy link

@dirkkul dirkkul commented May 11, 2022

Currently the tests assume an order of a node's children, however the description does not specify anything about the order.

Example:
Build for test case "three nodes in order" returned 0:[2:[] 1:[]] but was expected to return 0:[1:[] 2:[]].

I added an additional step in the test-code where the expected nodes and the actual nodes are sorted by their ID before comparing them and now the above example is accepted. I think that the order shouldn't matter in a tree, if anyone thinks otherwise I'm happy to extend the description instead.

@github-actions
Copy link
Contributor

Dear dirkkul

Thank you for contributing to the Go track on Exercism! 💙
You will see some automated feedback below 🤖. It would be great if you can make sure your PR covers those points. This will save your reviewer some time and your change can be merged quicker.

  • ⬆️ The instructions and test cases for many practice exercises originate in the Exercism-wide problem-specifications repo. If the exercise you changed is listed there in the exercises folder, please consider the following.

    • Improvements to the instructions.md file should be made in the problem-spec repo so that all tracks can benefit.
      You can open a PR there instead.
    • If you want to add some language specific information, use the instructions.append.md file (see Practice Exercise Docs).
    • Test cases selected in the .meta/tests.toml file need to be implemented in the <exercise>_test.go file according to the specification in canonical-data.json.
  • ✍️ If your PR is not related to an existing issue (and is not self-explaining like a typo fix), please make sure the description explains why the change you made is necessary.

  • 🔤 If your PR fixes an easy to identify typo, if would be great if you could check for that typo in the whole repo. For example, if you found Unicdoe, use "replace all" in your editor (or command line magic) to fix it consistently.

Dear Reviewer/Maintainer

  • 📏 Make sure you set the appropriate x:size label for the PR. (This also works after merging, in case you forgot about it.)

  • 🔍 Don't be too nit-picky. If the PR is a clear improvement compared to the status quo, it should be approved as clear signal this is good to be merged even if the minor comments you might have are not addressed by the contributor. Further improvement ideas can be captured in issues (if important enough) and implemented via additional PRs.

  • 🤔 After reviewing the diff in the "Files changed" section, take a moment to think about whether there are changes missing from the diff. Does something need to be adjusted in other places so the code or content stays consistent?

Automated comment created by PR Commenter 🤖.

Sorts expected and actual nodes by their ID before comparing them. Now the tests do not depend of providing the solution in a given order.
@dirkkul
Copy link
Author

dirkkul commented May 12, 2022

Now linting should be fine, made the edit at first via web-UI :)

@andrerfcsantos
Copy link
Member

@dirkkul Thanks for raising an issue about this! I agree that the order on a tree shouldn't matter. Not having this, requires having to sort the records before building the tree, which I agree might be busy work for the exercise. However, I took a peek at how other tracks were implementing this exercise and in their exemplar solutions, they also sort the records before building the tree. So this looks like it's something all tracks "suffer" from.

Instead of fixing this just in the Go track, I believe we should change the description in all tracks to make it clearer that some kind of sorting is needed. You can suggest a change to the description of the exercise by opening an issue in the problem-specifications about this asking if the description should be changed or if requiring some kind of sorting must be something that each track must decide individually. If the changes are agreed upon there, feel free to open a PR there implementing the changes, and that way all tracks will be able to benefit from it.

I'll close this for now, but if a conclusion is reached in problem-specifications is reached about this, feel free to ask for this PR to be reopened or create a new one bringing the changes from problem-specifications here to the Go track.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants