更新:这个故事的寓意是相信直觉，不要去寻找问题。最后，用户报告的问题是在一个完全不同的领域，正如Jon强调的那样，我们在测试中引入了一个错误，我们忽略了这个错误，因为结果似乎验证了我们所寻找的内容。
原始问题:在许多应用程序中，需要显示开始/结束日期，其中结束日期包含一个日历年。因此，如果开始日期是2012年1月1日，结束日期是2012年12月31日。基本规则是加一年，休息一天——作为一种扩展方法，你是:
public static DateTime CalendarYear(this DateTime dateTime)
{
return dateTime.AddYears(1).AddDays(-1);
}
但是，上面的代码不能处理闰年!在从2011年1月1日开始到2014年12月31日的测试中，我们的单元测试标记了365个预期日期与确定的结束日期不匹配的事件。定义错误边界的日期如下:
- 开始日期:2011年3月1日预计结束日期:2012年2月28日实际结束日期:2012年2月29日
- 开始日期:2012年2月28日，预计结束日期:2012年2月26日2013:实际结束日期:2013年2月27日
2011年3月1日之前的日期为预期日期，2012年2月28日之后的日期为预期日期。
我知道测试失败的原因是因为开始/结束日期包含2月29日闰年事件，但是是否有人有一个简单，可靠的建议(应对闰年事件)来取代基本的"AddYears(1).AddDays(-1)"来快速确定日历年?
在我看来，"实际"版本是正确的…为什么你期望从2月28日开始的"一年减一天"是2月26日?如果没有2月27日，你怎么能说它包含一个日历年呢?
如果你真的想要这些值，你是否考虑过只调用AddDays(364) ?
我一定是错过了一些非常明显的东西，如果我输入2011年3月1日，并执行add -1day，我得到的是我作为人类期望的2012年2月29日，如果我输入2012年2月28日，我得到的是2013年2月27日。如果你只想增加365天，那就这样做吧。我有点糊涂了。所以你的实际结果看起来是正确的。
还需要咖啡吗?