Two-Bucket has an incorrect test

[glennj]

The number of moves for the 6th test is wrong.

  describe('Measure using bucket one of size 2 and bucket two of size 3', () => {
    xtest('start with bucket one and end with bucket two', () => {
      const twoBucket = new TwoBucket(2, 3, 3, 'one');
      expect(twoBucket.moves()).toEqual(4);
      expect(twoBucket.goalBucket).toEqual('two');
      expect(twoBucket.otherBucket).toEqual(1);
    });
  });

The number of moves should be 2:

1. fill the start bucket
2. since the other bucket size == the goal, fill it
3. there is no move 3.

Following that change, the otherBucket amount should be 2 (the start bucket is full).

I humbly suggest my solution as a reference solution.

This was changed in #1396.

[junedev]

Thanks for the report! We were planning a wider check what's out of sync once the new configlet release lands that allows to also sync instructions.

Here the task list to fix this issue for whoever wants to work in this:

• Use configlet sync to update the tests.toml file.
• Fix the test cases so they match the latest version defined in problem spec.
• Update the example solution (see suggestion above).

[joshgoebel]

@SleeplessByte We had a bit of a discussion about memoizing vs erroring for the result accessors. Evidently we were both suggesting slightly different directions (in our mentoring with Glenn). I dislike students "over-engineering" solutions (unless that's declared to be the game). I think adding a bunch of "throw errors" or "call move magically" is too much given that the tests specify no behavior in a

new TwoBucket(...).goalBucket

scenario. IE, it's expected one simple doesn't ask for a result until after move has been called. So, what should happen if someone doesn't do that?

• Should it error?
• Should it just perform the calculation and return the result?
• Perhaps this behavior should be based on whether a prior result was cached or not?
• Other options I haven't thought of?

For these reasons I'd say documenting the behavior as returns null or throwing an error is better - but since the tests specify neither I'm not sure either is required for a solid Exercism solution here. For an actual client or FOSS library obviously you'd want to lock this type of behavior down in a more professional fashion. So there are good conversations that can happen with students around this.

BUT I'm wondering if we should just change this API to avoid the problem entirely... One solution would be that a result object is directly generated) and returned by the move method:

buckets = new TwoBucket(...)
bucket.move() => // { goalBucket: "two", otherBucket: 0 }

Now one doesn't even have to scratch their head over the correct behavior. It's simply impossible to try to work with the result before it's been generated since the result is it's own discrete object.

Thoughts? If this is too off-topic it can be split into a second issue.

[SleeplessByte]

I'll think about it for a hot minute, but i like how you've written down your thoughts!