Update tests two bucket

[jagdish-15]

Pull Request

This PR adds 3 new tests to the Two Bucket exercise to sync with the problem-specifications repository. Two of the newly added tests check for error handling, which was not tested before. I am also unsure about the error message—should I keep it as it is in the problem-specifications repo or modify it to be more informative?

Let me know your thoughts on this.

---

Reviewer Resources:

Track Policies

[kahgoh]

I think with the error messages I think it is fine to leave them out of the exception. But, I think we should make our own exception instead of reusing IllegalArgumentException. IllegalArgumentException is used to indicate when one of the arguments to the method is bad (like if if one of them is negative). It doesn't suit cases where the arguments are good, but we can't reached the required amount. If we can't reach the value, I'd use a different exception, perhaps making a custom one for the exercise.

[jagdish-15]

@kahgoh, thank you for the suggestion—it does make a lot of sense to create a custom exception for this purpose.
I imagine it would look something like this:

public class UnreachableGoalException extends RuntimeException {
    public UnreachableGoalException() {
        super();
    }

    public UnreachableGoalException(String message) {
        super(message);
    }

    public UnreachableGoalException(String message, Throwable cause) {
        super(message, cause);
    }
}

That said, when I think about this, we've used IllegalArgumentException in similar scenarios before—like when the target amount couldn't be reached with the available denominations in the "Change" exercise. I've noticed this approach across many other exercises as well. (But some exercises like "Calculator Conundrum" do use custom exceptions)

While your suggestion is undoubtedly a more "proper" and robust approach, it might feel a little inconsistent with the conventions used elsewhere. What are your thoughts on this? How do you think I should proceed?

[kahgoh]

I think there is also precedence for making our own exceptions for our exercises, like BinarySearch and TreeBuilding. But yeah, the think the exception would look something like that.

[jagdish-15]

Sure, I'll get right on it as soon as possible, since I already have the body of the custom Exception ready. However, I'll implement it the way it's done in exercises like "Binary Search" and "Tree Building," instead of following the approach in "Calculator Conundrum," as that causes build failure issues for Windows users (as highlighted in the forum discussion).

I was also considering implementing similar custom Exceptions in exercises like "Change," since an unassignable change value shouldn’t technically throw an IllegalArgumentException. If you have other exercises in mind that would benefit from custom Exceptions, feel free to let me know. We could even extend this improvement across the entire track—I’d be more than happy to take on that task!

[kahgoh]

However, I'll implement it the way it's done in exercises like "Binary Search" and "Tree Building," instead of following the approach in "Calculator Conundrum," as that causes build failure issues for Windows users (as highlighted in the forum discussion).

Sounds good. Feel free to update "Calculator Conundrum" as well.

I was also considering implementing similar custom Exceptions in exercises like "Change," since an unassignable change value shouldn’t technically throw an IllegalArgumentException

I'm reluctant to make this change in the other exercises. On one hand, I agree that there are other exercises where a custom exception makes sense. But on the other hand, wouldn't it mean solutions that students have already submitted become invalid if they use the custom exception? A lot of the community solutions would become invalid or outdated. The change would likely require the system to re-run tests on existing solutions, which incurs a cost (if you're interested, there is a note about expensive operations in Avoiding triggering unnecessary test runs). I'm not quite sure if the benefit is worth the cost from making the change.

[jagdish-15]

Sounds good. Feel free to update "Calculator Conundrum" as well.

Great! I'll get to updating "Calculator Conundrum" and this exercise as soon as possible—sorry for the delay!

Regarding the change to custom exceptions in other exercises, I completely agree with your point about the cost and the potential impact on existing solutions. Updating all exercises to use custom exceptions would indeed risk invalidating many community solutions, requiring a system-wide test rerun, which can be resource-intensive.

For this particular exercise, however, the situation seems different. Since the tests have been updated from the problem-specification repository, community solutions for this exercise are already going to be invalidated. If updates from the problem-specification repo are frequent and similar changes would cause solutions to become outdated anyway, we could consider making this adjustment now.

That said, it really comes down to the priority and whether the benefits of introducing custom exceptions outweigh the potential disruption. Let me know what you decide!

[kahgoh]

For this particular exercise, however, the situation seems different. Since the tests have been updated from the problem-specification repository, community solutions for this exercise are already going to be invalidated. If updates from the problem-specification repo are frequent and similar changes would cause solutions to become outdated anyway, we could consider making this adjustment now.

I agree, I think updating the Two Buckets exercise to meet the problem specifications and using the custom exception is fine. Its only updating the other exercises to use a custom exception like "Change" I'm reluctant to if they currently "work" with IllegalArgumentException.

[kahgoh]

For this particular exercise, however, the situation seems different. Since the tests have been updated from the problem-specification repository, community solutions for this exercise are already going to be invalidated. If updates from the problem-specification repo are frequent and similar changes would cause solutions to become outdated anyway, we could consider making this adjustment now.

I agree, I think updating the Two Buckets exercise to meet the problem specifications and using the custom exception is fine. Its only updating the other exercises to use a custom exception like "Change" I'm reluctant to if they currently "work" with IllegalArgumentException.

[kahgoh]

I think it is a bit odd to have to have to assert that we get an exception three times in the test (I was expecting only one assertion). What do you think about refactoring to assert the exception just once? In the csharp implementation, the TwoBucket class has a measure method that the tests calls. It returns a "Result" object containing the number of moves, the final bucket and the other bucket or throws an exception if the goal can be reached.

[jagdish-15]

I think it is a bit odd to have to have to assert that we get an exception three times in the test

Even I found it a bit odd to assert the exception three times while implementing the tests but couldn’t think of a better alternative. However, your suggestion of returning a Result object and handling everything within a single method is an excellent idea! This approach not only simplifies the implementation but also ensures the custom exception can be thrown effectively. Should I go ahead with this approach?

[kahgoh]

Yeah, I think we can go ahead with this one as we both seem to agree it would be better this way.

[kahgoh]

Yeah, I think we can go ahead with this one as we both seem to agree it would be better this way.