[
https://issues.apache.org/jira/browse/FINERACT-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270803#comment-17270803
]
Petri Tuomola commented on FINERACT-1293:
-----------------------------------------
Hi
Every time I've looked at these issues, they've been all related to interest
calculation. And when something goes wrong, it usually affects multiple tests:
so when there's something funny going on with number of days in month, or
initial date vs test date vs interest date, it usually affects multiple
products and hence multiple tests.
The fundamental issue here is that we calculate the expected interest
differently in the test and in the real code. The real code is much more
correct/accurate, the test code is a crude approximation - hence often gets it
wrong in corner cases. But if we used the real code in both cases then it would
be of course meaningless as a test: we'd test the same code against itself.
The only two options to fix this "properly" are:
# Continue improving the test code as we see corner cases. This is very
wasteful as we are basically rebuilding the same logic into the test as we
already have in the real code.
# Remove any dependency on the test code to "today" and instead use absolute
dates.
The reason the tests currently break is because many of the dates are
calculated related to "TODAY" - i.e. "start a loan 4 months ago and then see
what the balance is today". The problem comes when the date "4 months ago" is
somehow different than what was expected when the test was written - e.g. it's
in a different year, or there's a leap day, or there's a month end very close
to either start or end date, or is a weekend/non-banking day, or one of the
intermediate dates when you then move forward from it for 1 month at at time is
an non-banking day etc".
If, instead of building dates related to "today" we would always use a
fixed/absolute date as a start/disbursement date etc then these problems would
go away - the relationships between the dates would always be the same.
But that will require rewriting all the tests and recalculating the expected
values. Still time better spent than continuously enhancing / debugging the
test login imho.
Note that I'm commenting based on investigation of the other test failures that
I've looked at. I haven't investigated this particular one, so it is very
possible that this is about something else...
> SchedulerJobsTestResults testInterestTransferForSavings() and
> testExecuteStandingInstructionsJobOutcome() fail when run locally, but pass
> on Travis CI
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FINERACT-1293
> URL: https://issues.apache.org/jira/browse/FINERACT-1293
> Project: Apache Fineract
> Issue Type: Bug
> Reporter: Michael Vorburger
> Priority: Major
>
> While locally investigating FINERACT-924, I've found that the problem from
> that issue (the testApplyAnnualFeeForSavingsJobOutcome()) WORKED locally for
> me, but instead 2 other tests locally consistently failed on me, even though
> they do seem to always pass on Travis CI, namely:
> {noformat}
> org.opentest4j.AssertionFailedError: Verifying opening Balance ==> expected:
> <100000.0> but was: <100918.32>
> at
> org.apache.fineract.integrationtests.SchedulerJobsTestResults.testInterestTransferForSavings(SchedulerJobsTestResults.java:897){noformat}
> and:
> {noformat}
> org.opentest4j.AssertionFailedError: Verifying From Savings Balance after
> Successful completion of Scheduler Job ==> expected: <500.0> but was: <1000.0>
> at
> org.apache.fineract.integrationtests.SchedulerJobsTestResults.testExecuteStandingInstructionsJobOutcome(SchedulerJobsTestResults.java:659){noformat}
> This already came up back in FINERACT-857, where I had suspected that
> _"perhaps these individual test methods are not as isolated from each other
> as they should be"_.
> Or maybe that has something to do with the {{export TZ=Asia/Kolkata}} in
> [https://github.com/apache/fineract/blob/develop/.travis.yml#L55] ?
> [~ptuomola] (or perhaps [~aleks]) I don't suppose you happen to know more
> about this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
