I see now you aren’t doing unit testing, you are doing integration testing and automation. I was trying to isolate components, which isn’t the point here. Thanks for clearing that up with me.

The test code in this case is driving a Watij library which is driving a web browser to directly test the web pages, therefore the tests need to be able to operate against the current system.

Take a look at this for more information: http://www.slideshare.net/jsonmez/internal-ds-ls-for-automated-functional-testing

No worries, just making sure we are on the same page.

Is it correct to say that you are using DateTime.Now directly in your code, and that is the reason why the tests won’t be valid next month?

In that example, the problem would be that you can only run future eligibility months on the system, not past ones. So if you hard coded dates for creating a case for July 2010, and a 19 year old person, next month the test would not work.

Let me know if that makes it clear now. Sorry, I assumed too much domain knowledge.

Hi John,

I guess I don’t see where in your post you explain why hard-coded dates are undesirable. I understand your reasoning from that point forward, but I am unclear as to how you got there. Perhaps you could elaborate on why you are avoiding hard-coded dates in the first place?

I am unclear on the requirement “I need the ages and application dates to be able to move up with the real time”, which is probably why I am having difficulty understanding your position.

I understand what you are saying, but in this case I need the ages and application dates to be able to move up with the real time.

In this case I was creating an API for automated functional testing through the API.

Let me give you an example and see if this clears up what I was talking about.

Lets supposed I needed to created a brand new application with 19 year old on it.

I need the application date to be the current month… so CaseDate.CurrentMonth

I need the person to be 19 years old, so I use CaseDate.YearsAgo(19).

That test data will always be valid, regardless of the current year or time.

The idea is that the problem domain doesn’t really care about specific dates, it cares about relative dates.

Now, I agree with @Martin on not using DateTime in your code. You can synthetically produce dates, but that is a different matter than what I am addressing here.

The problem, then, is that you are unable to isolate the code being tested from the system clock. They are inherently coupled in such a way that all system clients must account for it. The CaseDate class merely treats the symptom, not the disease.

Were you to follow @Martin Jul’s suggestion (which I favor as well), you would be able to declare the value of “now” for any given test. Hard-coded dates are then perfectly acceptable because “now” is hard-coded as well.

Taking it further, what if you have a rule that takes effect in 2015, and you need to test it before it goes into production? Will you set your system clock ahead to run the test, and expect other devs to do the same? It makes more sense to abstract away the source of the “now” value, which is the intent of the ITimestampProvider suggestion.

(I realize this is not a use case of your system, but those kinds of rules are very relevant when giving general advice on handling dates.)

void SomeMethod(Decimal winProbability)

or

void SomeMethod(Probability winProbability)

In other words, you are not just “forcing” your API user, you are also helping him to understand your API.

Hi Rob,

I think you are missing it. caseDate.Date does not have a setter in my implementation.

The whole point is to make sure that raw dates are not used, instead one of the methods I provide on my custom date class is used to construct the date.

This prevents any dates from being hard-coded, since it is not possible to call the API without using the CaseDate class, and the date can not be set manually in the CaseDate class.

The problem, then, is that you are unable to isolate the code being tested from the system clock. They are inherently coupled in such a way that all system clients must account for it. The CaseDate class merely treats the symptom, not the disease.

Were you to follow @Martin Jul’s suggestion (which I favor as well), you would be able to declare the value of “now” for any given test. Hard-coded dates are then perfectly acceptable because “now” is hard-coded as well.

Taking it further, what if you have a rule that takes effect in 2015, and you need to test it before it goes into production? Will you set your system clock ahead to run the test, and expect other devs to do the same? It makes more sense to abstract away the source of the “now” value, which is the intent of the ITimestampProvider suggestion.

(I realize this is not a use case of your system, but those kinds of rules are very relevant when giving general advice on handling dates.)