Hi, good points about testing time dependent functionality.
There are more possible problems, e.g. the definition of a month. The silent assumption in your code is that a month counts 31 days. For Christmas on Dec. 25th, a month earlier should start on Nov. 25th. With your current code it will start on Nov. 24th. Thus, I would rephrase the condition in the method and check if the current month is the month of Christmas (December) or one earlier (November) + checking days.
Another issue with time-related tests are timezones. Should we count time in the timezone of the application calling the method or the place where the method is called? e.g. someone in Canada is running this code in Germany, where the code is stored and run – what timezone should be used to get consistent results?
You are absolutely right, there are many things that could be issues with the code in my example. The length of a month can be argued. Should it be 28, 29 (it happens) or 30 days? How should timezones be handled? These are things you have to understand and decide. Then there is the control part, avoid to rely on the system date for testing. It moves on and your test has to cope with a moving target. Moving targets are always more difficult to handle than stationary targets.
Testing is difficult without understanding the problem and controlling the testing environment.
There are two different categories here.
* The business part, the length of a month, when is Christmas celebrated and how should timezones be handled.
* The technical part, how can you isolate the system under test so you don’t get dependencies that you don’t have control over.
The business part is something you might have to accept and just relate to. The technical part is where you, as a developer and tester, have to take control and implement what you need in order to solve the problem.