[
https://issues.apache.org/jira/browse/NUMBERS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843441#comment-16843441
]
Heinrich Bohne commented on NUMBERS-99:
---------------------------------------
Regarding your point about multiple test methods: Do you mean the fact that
{{FractionTest.testAdd()}} now tests both {{Fraction.add(Fraction)}} and
{{Fraction.add(int)}}, and that it would be more appropriate to create a
separate test method for {{Fraction.add(int)}}? The reason I didn't do it this
way was that the method {{FractionTest.testAdd()}} already contained a section
where {{Fraction.add(int)}} was tested among all the other tests of
{{Fraction.add(Fraction)}}, so I thought the test would belong there.
The same applies to the test where an exception is expected. I tried to follow
the style of the other tests where an exception is expected (which are present
in abundance, and they all swallow the exception without the test method being
annotated as you describe). So if I understand you correctly, the code in the
test class was already not following the guidelines you mentioned here, and
should therefore be rewritten?
> Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
> ----------------------------------------------------------------------------
>
> Key: NUMBERS-99
> URL: https://issues.apache.org/jira/browse/NUMBERS-99
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
> Reporter: Heinrich Bohne
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The methods {{add(int)}} and {{subtract(int)}} in the class
> {{org.apache.commons.numbers.fraction.Fraction}} do not take into account the
> risk of an integer overflow. For example, (2^31^ - 1)/2 + 1 = (2^31^ +
> 1)/2, so the numerator overflows an {{int}}, but when calculated with
> {{Fraction.add(int)}}, the method still returns normally.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
