Thoughts on tests for robot-name

I’m implementing robot-name for moonscript

I’ve included a test for generating all the robots and then one more.

There are a couple of dozen tracks that implement robot-name and, from peeking into a few of them, not many test for all the robots.

This exercise does not have canonical data.

Maintainers, what are your thoughts about this?

My first reaction is that it might be a good test to add … provided you think that the average student could make code efficient enough that it wouldn’t topple or time out the test runner/container.

I honestly don’t know (so will be running away to see if that test would work for Python) – but my “spidey sense” is somewhat tingling around timeouts. Could be utter fantasy on my part. :woman_shrugging:

Also – canonical data would be nice for this exercise. :smile:

1 Like

I’m a definite +1 for adding canonical data, but I’m not convinced there’s a lot of utility in adding a test that maintainers may end up not including due to timeout concerns.

1 Like

I’m +1 for adding canonical data.

Regarding testing all possible names, I share Bethany’s concern. Since names are expected to be random and unique, a common approach would be to keep track of previous names and, if a new name is not unique, retry. I’m guessing that this would lead to timeouts on some tracks.

1 Like

I’d love to see canonical data here though due to the nature of this exercise I expect the tests would be descriptive and test generators wouldn’t really make sense. I’d be curious to see what the date might look like.

Yeah the “all names” test might be commented out as a challenge to smartypants students.

1 Like

From experience, it does.

1 Like

I’m not sure I would know where to start. It’s an exercise about randomness, so there would have to be some vagueness like dnd-character.

Also how to encode pattern matching in canonical data: “the robot name must match the pattern ‘letter, letter, digit, digit, digit’” – can’t do that with a regex, not every language implements regular expressions.

But I suppose it’s worth encoding the tests that are commonly implemented, even in just descriptions. I’ll give that a shot in the coming days.

For the timeout concerns, I did add a hints file

Performance Hints

  • A good strategy for assigning names to all the robots is to generate all 676,000 names first and shuffle that list. Then, each new robot can simply take the next name from the shuffled list.

I thought that was specific enough without giving too much away.

This is a nuanced exercise. If you only plan on making a “few” robots, generating and storing the full name list is overkill. If you plan on making every robot, it’s very helpful. Knowing how many robots you plan on making strongly influences if that’s a useful approach. Or, if you’re into over engineering, you can generate the full list after you’ve passed some threshold.

A quick update

  • Tcl and Wren already include the “all names” test. I’m responsible for that.
  • JavaScript and TypeScript include the test, but skip it in the test runner.
  • Nim hides the test behind a boolean flag that students can override.
  • Ruby includes the test but adds a 60 second timeout

I think I like the Nim approach best.

Update: guard added for Tcl

Update: guard added for Wren

Update: merged into MoonScript