I've created a pull request:
https://github.com/apache/commons-numbers/pull/55
This pull request exterminates most the code duplication between the two
classes. There is still some duplication left, most notably in the
method testDigitLimitConstructor(), but I've found out that the
Fraction(doubl
>
> > If additional context is required it fails to meet the definition of
> > a unit test and is instead an integration test, and the function being
> > tested may require rethinking.
>
> Depends what you define as a unit test. I'd say the unit was BigFraction
> or Fraction. An integration test i
By the way, I've worked a bit on the draft in the meantime and pushed
the changes I've made so far, in case anyone is interested in
(re-)viewing them. Here's the link to the branch again:
https://github.com/Schamschi/commons-numbers/tree/FractionCommonTestCases
On 6/20/19 6:13 PM, Heinrich Bohne
Hello Eric,
I'm not sure if I understand what you mean by "context" when you say
that all context has to be within the unit test.Do you mean that the
test should not rely on the functionality of other
modules/methods/"units" than the one to be tested? If so, I agree with
you, but I don't think th
On 20/06/2019 16:07, Eric Barnhill wrote:
Sorry for the slow reply, I thought I sent this yesterday.
I agree from a code architecture standpoint such a refactoring makes sense.
However from the perspective of unit tests it makes it no longer a unit
test.
It is still testing a unit. Just the test
Sorry for the slow reply, I thought I sent this yesterday.
I agree from a code architecture standpoint such a refactoring makes sense.
However from the perspective of unit tests it makes it no longer a unit
test.
IIUC it's best practice for a unit test that all context be within the
test. If addi
A quick looks shows that the BigFractionTest does have test cases for very
large numbers. However the add, subtract, divide and multiply tests and a few
others just use values that would work with Fraction. Possibly these can be
moved to a shared common tests location too.
That's what I was t
> On 20 Jun 2019, at 00:54, Heinrich Bohne wrote:
>
> An awful lot of code is duplicated between FractionTest and
> BigFractionTest. Often, the test cases in the two classes only differ in
> the types they use (e.g. Fraction vs. BigFraction), but the actual
> values the tests use are the same.
An awful lot of code is duplicated between FractionTest and
BigFractionTest. Often, the test cases in the two classes only differ in
the types they use (e.g. Fraction vs. BigFraction), but the actual
values the tests use are the same.
I think this could be mitigated by adding a new class that sto
