Upgrade to version 3 spec

This topic to discuss upgrade ruby test runner to spec version 3. I created PR for this feature, but it was closed :frowning:. I would like to discuss exactly this PR and the way how to better implement this.
My proposition is to add to test special comment with task_id value like this

def test_empty_strands
  ### task_id: 1
  # skip
  assert_equal 0, Hamming.compute('', '')
end

and final results.json should look like

{
  "version": 3,
  "message": null,
  "status": "pass",
  "tests": [
    {
      "name": "Empty strands",
      "status": "pass",
      "task_id": 1,
      "test_code": "assert_equal 0, Hamming.compute('', '')"
    }
  ]
}

If here are any ideas how to do it with better way – welcome to conversation.

Thanks for the PR. It got closed automatically rather than as a rejection of the work, but chatting here to agree the methodology is a good thing anyway :slight_smile:

I’d be happy with the approach you’ve taken, although I’d probably rather prefer a method like task(1) above the test, so

task(1)
def test_empty_strands
  # skip
  assert_equal 0, Hamming.compute('', '')
end

I feel like that reads a bit nicer. However, this might be hard to pull off for CLI users who don’t have our test runner that can inject stuff.

As a secondary option, I’d rather have the comment on the line before the test with just one hash. For example:

# task: 1
def test_empty_strands
  # skip
  assert_equal 0, Hamming.compute('', '')
end

That feels a bit more metadatay to me, and one # is inline with how other ruby special comments work (e.g. frozen_string_literal: true).

Thoughts?

Hello.
After a long pause (during which I lost and found a new job) I would like to return and finish this task.
@iHiD so, about your prepositions about how to mark task_id. In my opinion, better to do like a comment, outside or inside the method. It’s more easy to implement and does not add increased complexity.

As far as supporting task 1 behavior, we could publish a gem for Exercism’s Ruby track that made that available for our local developers.

Similar for the debug that is currently used, though I would prefer overloading p for the platform’s use, and having it be allowed on the platform for that reason.

Yeah, that could be useful. We “just” need to decide on what it should look like in code. Any ideas kotp?

Similar to Jeremys gem that we use… memoize I think it is (have not looked at it recently)… we would probably write the method task as a Kernel method, but if it is isolated to Minitest, then perhaps it would be effectively a patch for that.

Since it appears this would only happen in the tests, the Minitest patch would likely be the way to go.

We would update the instructions for the students working locally, to gem install exercism-exercise-task depending on the name, but prefixing the name with the organization is helpful to avoid name-clashes.

This also means there would be no need to comment that, as it would be a “thing”. Perhaps, since the tests run sequentially on the platform, would be something that forces sequential test order as well, but could be given an argument to allow a random order.

Sounds good. I would probably argue for exercism-test or exercism-tests to make it a bit more generic, which would allow us to add more to it later on.

1 Like

:+1: for exercism-tests. I’ll create the GH repo and the gem next week, and put a first-pass of the code in it.

The only disadvantage of this is that we need to tell people to install a 3rd party dependency and need to update all test files on the track to handle this. I’ll put together a sample PR for this too.

We already ask them to install a third party dependency, which is the exercism cli, (or is that “second party” to the first party, the first party being the language they are practicing, the second party being Exercism?).

We also ask contributors to run configlet, as well. So it is just another tool in the tool box for Exercism.

The update for the exercises may be a gemfile that is placed when an exercise for the Ruby track is downloaded for the first time, otherwise yes, instructions file/help file likely would need to be updated.

Maybe make a gem called exercism-test and then organize it for sub-features that can be isolated, such as require exercism-test/tasks for example.

This may be "exercism-ruby` gem with the same idea so that the name-space is reserved to some extent, as well.