¿Cuál es una buena manera de sobrescribir DateTime.Now durante la prueba?

Tengo un código (C #) que se basa en la fecha de hoy para calcular correctamente las cosas en el futuro. Si utilizo la fecha de hoy en la prueba, tengo que repetir el cálculo en la prueba, lo cual no me parece correcto. ¿Cuál es la mejor manera de establecer la fecha en un valor conocido dentro de la prueba para que pueda probar que el resultado es un valor conocido?

Mi preferencia es que las clases que usen el tiempo realmente dependan de una interfaz, como

interface IClock
{
    DateTime Now { get; } 
}

Con una implementación concreta

class SystemClock: IClock
{
     DateTime Now { get { return DateTime.Now; } }
}

Luego, si lo desea, puede proporcionar cualquier otro tipo de reloj que desee para la prueba, como

class StaticClock: IClock
{
     DateTime Now { get { return new DateTime(2008, 09, 3, 9, 6, 13); } }
}

Puede haber algunos gastos generales al proporcionar el reloj a la clase que depende de él, pero eso podría ser manejado por cualquier cantidad de soluciones de inyección de dependencia (usando un contenedor de Inversión de Control, una inyección simple de constructor / configurador antiguo o incluso un Patrón de Puerta de Enlace Estático ).

Otros mecanismos de entrega de un objeto o método que proporciona los tiempos deseados también funcionan, pero creo que la clave es evitar reiniciar el reloj del sistema, ya que eso solo introducirá dolor en otros niveles.

Además, usarlo DateTime.Nowe incluirlo en sus cálculos no solo no se siente bien, sino que le priva de la capacidad de probar momentos particulares, por ejemplo, si descubre un error que solo ocurre cerca de un límite de medianoche o los martes. Usar la hora actual no le permitirá probar esos escenarios. O al menos no cuando quieras.

Ayende Rahien utiliza un método estático que es bastante simple ...

public static class SystemTime
{
    public static Func<DateTime> Now = () => DateTime.Now;
}

Creo que crear una clase de reloj separada para algo simple como obtener la fecha actual es un poco exagerado.

Puede pasar la fecha de hoy como parámetro para poder ingresar una fecha diferente en la prueba. Esto tiene el beneficio adicional de hacer que su código sea más flexible.

Usar Microsoft Fakes para crear una corrección es una forma realmente fácil de hacer esto. Supongamos que tuviera la siguiente clase:

public class MyClass
{
    public string WhatsTheTime()
    {
        return DateTime.Now.ToString();
    }

}

En Visual Studio 2012, puede agregar un ensamblaje de falsificaciones a su proyecto de prueba haciendo clic con el botón derecho en el ensamblaje para el que desea crear falsificaciones / calzas y seleccionando "Agregar ensamblaje de falsificaciones".

Finalmente, así es como se vería la clase de prueba:

using System;
using ConsoleApplication11;
using Microsoft.QualityTools.Testing.Fakes;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace DateTimeTest
{
[TestClass]
public class UnitTest1
{
    [TestMethod]
    public void TestWhatsTheTime()
    {

        using(ShimsContext.Create()){

            //Arrange
            System.Fakes.ShimDateTime.NowGet =
            () =>
            { return new DateTime(2010, 1, 1); };

            var myClass = new MyClass();

            //Act
            var timeString = myClass.WhatsTheTime();

            //Assert
            Assert.AreEqual("1/1/2010 12:00:00 AM",timeString);

        }
    }
}
}

La clave para una prueba unitaria exitosa es el desacoplamiento . Debe separar su código interesante de sus dependencias externas, para que pueda probarse de forma aislada. (Afortunadamente, el desarrollo basado en pruebas produce código desacoplado).

En este caso, su externo es el DateTime actual.

Mi consejo aquí es extraer la lógica que trata con DateTime a un nuevo método o clase o lo que tenga sentido en su caso, y pasar el DateTime. Ahora, su prueba unitaria puede pasar un DateTime arbitrario, para producir resultados predecibles.

Otro que usa Microsoft Moles ( marco de aislamiento para .NET ).

MDateTime.NowGet = () => new DateTime(2000, 1, 1);

Moles permite reemplazar cualquier método .NET con un delegado. Moles admite métodos estáticos o no virtuales. Moles confía en el perfilador de Pex.

Sugeriría usar el patrón IDisposable:

[Test] 
public void CreateName_AddsCurrentTimeAtEnd() 
{
    using (Clock.NowIs(new DateTime(2010, 12, 31, 23, 59, 00)))
    {
        string name = new ReportNameService().CreateName(...);
        Assert.AreEqual("name 2010-12-31 23:59:00", name);
    } 
}

En detalle se describe aquí: http://www.lesnikowski.com/blog/index.php/testing-datetime-now/

Respuesta simple: deshazte de System.DateTime :) En su lugar, usa NodaTime y su biblioteca de prueba: NodaTime.Testing .

Otras lecturas:

• Prueba unitaria con Noda Time
• Inyección de dependencia: ¡Inyecte sus dependencias, punto!

Puede inyectar la clase (mejor: método / delegado ) que usa DateTime.Nowen la clase que se está probando. Debe DateTime.Nowser un valor predeterminado y solo configúrelo en las pruebas con un método ficticio que devuelva un valor constante.

EDITAR: Lo que dijo Blair Conrad (tiene un código para mirar). Excepto, tiendo a preferir delegados para esto, ya que no abarrotan su jerarquía de clases con cosas como IClock...

Me enfrenté a esta situación con tanta frecuencia que creé un nuget simple que expone la propiedad Now a través de la interfaz.

public interface IDateTimeTools
{
    DateTime Now { get; }
}

La implementación es, por supuesto, muy sencilla

public class DateTimeTools : IDateTimeTools
{
    public DateTime Now => DateTime.Now;
}

Entonces, después de agregar nuget a mi proyecto, puedo usarlo en las pruebas unitarias

Puede instalar el módulo directamente desde la GUI Nuget Package Manager o usando el comando:

Install-Package -Id DateTimePT -ProjectName Project

Y el código del Nuget está aquí .

El ejemplo de uso con Autofac se puede encontrar aquí .

¿Ha considerado usar la compilación condicional para controlar lo que sucede durante la depuración / implementación?

p.ej

DateTime date;
#if DEBUG
  date = new DateTime(2008, 09, 04);
#else
  date = DateTime.Now;
#endif

De lo contrario, desea exponer la propiedad para poder manipularla, todo esto es parte del desafío de escribir código comprobable , que es algo con lo que actualmente estoy luchando: D

Editar

Una gran parte de mí preferiría el enfoque de Blair . Esto le permite "conectar en caliente" partes del código para ayudar en las pruebas. Todo sigue el principio de diseño que encapsula lo que varía el código de prueba no es diferente al código de producción, es solo que nadie lo ve externamente.

Sin embargo, la creación de una interfaz puede parecer mucho trabajo para este ejemplo (razón por la cual opté por la compilación condicional).