[JSR-354] Re: JSR 354 API Update
- From: "Tresch Anatole (KFSC 225)" <anatole.tresch@...>
- To: <jcurrency_mail@...>
- Subject: [JSR-354] Re: JSR 354 API Update
- Date: Thu, 18 Jul 2013 15:03:27 +0200
I consider it to be quite small, also including conversion. In the conversion
area we cannot and should not test the provider's data quality, we can and
should test if the correct data items are selected and returned in the API
based on the SPI data returned. To ensure that we must have have full control
about the test cases, so we have to mock the complete SPI with some special
testing providers. That way we can ensure an implementation (including the
RI) will select and return the correct entries. Basically the same is true to
other functions that also support historization. In all such cases I do not
see a benefit from introducing such an additional mechanism into our
APIs/SPIs. If one would require such, it can still add them to the according
SPI implementations transparently.
CREDIT SUISSE AG
Information Technology | Java Core Framework & Support, KSXK 23
Zollstrasse 20/36 | 8070 Zürich | Switzerland
Phone +41 44 334 03 89
...> | www.credit-suisse.com
From: Werner Keil [mailto:werner.keil@...]
Sent: Thursday, July 18, 2013 10:34
Subject: [JSR-354] Re: JSR 354 API Update
Would we consider JSR 354 a small or big library?
If you take just the core part (Currency, Money even with implementations) it
is rather small, but if a few other parts, especially conversion come into
play, I am not sure. Where either test method was to allow it, adding some
mock framework could be worth a thought.
On Wed, Jul 17, 2013 at 9:15 PM, Anatole Tresch <atsticks@...> wrote:
Basically also in our bank such discussions were initiated. Basically, when
testing integrated systems this is a very functional way to simulate
different time scenarios, eg year end processing.
For testing smaller libraries i personally prefer to dynamically provide test
data or services/mocks for the corresponding tests. This, contrary to the
global solution, still allows isolation of my test cases/suites...
Tel +41 (43) 317 05 30
Send from Mobile
Am 17.07.2013 um 19:47 schrieb Werner Keil <werner.keil@...>:
This pattern for testing timestamps might be useful, too:
While it (obviously) uses long, such a layer could also allow using
multiple Date/Time APIs behind the scenes, and come handy for either simple
unit tests or maybe those in the TCK, too.
Since most parts of the API tend to consume a timestamp, using such
an interface as part of the actual API may not help much, there, or does
anybody feel it would benefit?