Write complete and detailed test code for Date

Bug #1209742 reported by Richard Gomes
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
JQuantLib
Won't Fix
High
Richard Gomes

Bug Description

This task consists on reviewing QuantLib/C++ Date against our Date interface, implementing the missing methods and writing additional test cases in order to make sure that the API is expressive and intuitive enough. Some background regarding this task is as follows.

I detected that interface Date had some methods missing. In particular, some methods involving Period were missing and methods for adding and subtracting dates were missing. This fact leaded to side effects on other classes which make use of Date.

A good example is: we'd like to calculate a date which is 3 years in the future from the current business day. The code I found was:

Settings s = Configuration.getSystemConfiguration(null).getGlobalSettings();
Date today = s.getEvaluationDate();
Date newDate = today.increment(3 * Period.ONE_YEAR_FORWARD.getLength());

... which seems to be OK at first glimpse but in fact, is copiously wrong for these reasons:

1. getEvaluationDate does not guarantee we have a business day in our hands;
2. getLength() returns the length of a period. In this case it's 1, i.e. 1 year. It means we are incrementing today by 3, i.e: 3 days.
3. increment changes the calling object. It means that todays 'is not today anymore' :(

The correct code would be:

Calendar calendar = Target.getCalendar();
Date today = calendar.advance(DateFactory.getFactory().getTodaysDate());
Date newToday = today.plus(Period.ONE_YEAR_FORWARD.times(3));

I implemented times, plus and minus. I added the option of passing a Period to these and some other methods.

More test cases are needed in order to exercise the API and detect situations like the shown above, where something 'seems' to be OK but is the other way round.

=============
Relationships
=============
has duplicate http://bugs.launchpad.net/bugs/jquantlib-396
related to http://bugs.launchpad.net/bugs/jquantlib-380
child of http://bugs.launchpad.net/bugs/jquantlib-327

Tags: tests
Revision history for this message
Srinivas Hasti (shasti) wrote :

To avoid these kind of pit falls, we should make the methods that update the state of a current instance not to return itself. Though this means little bit deviation from quantlib, i think its in our better interest to provide a cleaner api.

Revision history for this message
Richard Gomes (frgomes) wrote :

This issue became absolutely outdated after Date and Calendar were rewritten.

In spite the need of complete test cases persist, it's better close this issue and open another one, in order to avoid confusion.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.