Skip to main content

[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

Hi Werner/all

 

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.

 

Regards,

 

Anatole Tresch

CREDIT SUISSE AG

Information Technology | Java Core Framework & Support, KSXK 23

Zollstrasse 20/36 | 8070 Zürich | Switzerland

Phone +41 44 334 03 89

anatole.tresch@... <mailto:anatole.tresch@...>  | www.credit-suisse.com 
<http://www.credit-suisse.com

 

From: Werner Keil [mailto:werner.keil@...] ;
Sent: Thursday, July 18, 2013 10:34
To: jcurrency_mail@...
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.

 

Werner

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...

 

Cheers


-

Anatole Tresch

Glärnischweg 10

8620 Wetzikon

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: 
http://www.javapractices.com/topic/TopicAction.do?Id=234 ;

        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?

         

        Werner

Attachment: image001.gif
Description: image001.gif



[JSR-354] Re: JSR 354 API Update

Werner Keil 07/16/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/17/2013

[JSR-354] Re: JSR 354 API Update

Anatole Tresch 07/17/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/18/2013

[JSR-354] Re: JSR 354 API Update

Tresch Anatole (KFSC 225) 07/18/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/18/2013

[JSR-354] Re: JSR 354 API Update

Sascha Freitag 07/28/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/28/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/29/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/30/2013

[JSR-354] Re: JSR 354 API Update

Sascha Freitag 07/30/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 07/30/2013
 
 
Close
loading
Please Confirm
Close