Qual é uma boa maneira de substituir DateTime.Now durante o teste?

Eu tenho alguns códigos (C #) que dependem da data de hoje para calcular corretamente as coisas no futuro. Se eu usar a data de hoje no teste, tenho que repetir o cálculo no teste, o que não parece certo. Qual é a melhor maneira de definir a data para um valor conhecido no teste para que eu possa testar se o resultado é um valor conhecido?

Minha preferência é ter aulas que usam o tempo na verdade dependem de uma interface, como

interface IClock
{
    DateTime Now { get; } 
}

Com uma implementação concreta

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

Então, se quiser, você pode fornecer qualquer outro tipo de relógio que deseja para teste, como

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

Pode haver alguma sobrecarga em fornecer o relógio para a classe que depende dele, mas isso pode ser tratado por qualquer número de soluções de injeção de dependência (usando um contêiner de Inversão de Controle, injeção simples de construtor / setter ou até mesmo um Padrão de Gateway Estático )

Outros mecanismos de entrega de um objeto ou método que fornece os tempos desejados também funcionam, mas acho que o principal é evitar redefinir o relógio do sistema, já que isso apenas introduzirá dor em outros níveis.

Além disso, usá DateTime.Now-lo e incluí-lo em seus cálculos não parece certo - ele rouba a capacidade de testar horários específicos, por exemplo, se você descobrir um bug que só acontece próximo ao limite da meia-noite ou às terças-feiras. Usar a hora atual não permitirá que você teste esses cenários. Ou pelo menos não quando quiser.

Ayende Rahien usa um método estático que é bastante simples ...

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

Acho que criar uma classe de relógio separada para algo simples como obter a data atual é um pouco exagero.

Você pode passar a data de hoje como um parâmetro para que possa inserir uma data diferente no teste. Isso tem o benefício adicional de tornar seu código mais flexível.

Usar o Microsoft Fakes para criar um shim é uma maneira realmente fácil de fazer isso. Suponha que eu tivesse a seguinte aula:

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

}

No Visual Studio 2012, você pode adicionar um assembly Fakes ao seu projeto de teste clicando com o botão direito do mouse no assembly para o qual deseja criar Fakes / Shims e selecionando "Add Fakes Assembly"

Finalmente, aqui está a aparência da classe de teste:

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);

        }
    }
}
}

A chave para um teste de unidade bem-sucedido é o desacoplamento . Você tem que separar seu código interessante de suas dependências externas, para que ele possa ser testado isoladamente. (Felizmente, o Desenvolvimento Orientado a Testes produz código desacoplado.)

Neste caso, seu externo é o DateTime atual.

Meu conselho aqui é extrair a lógica que lida com DateTime para um novo método ou classe ou o que fizer sentido no seu caso, e passar DateTime. Agora, seu teste de unidade pode passar um DateTime arbitrário para produzir resultados previsíveis.

Outra usando Microsoft Moles ( Isolation framework for .NET ).

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

Moles permite substituir qualquer método .NET por um delegado. Moles suporta métodos estáticos ou não virtuais. Moles depende do profiler de Pex.

Eu sugiro usar o padrão 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);
    } 
}

Descrito em detalhes aqui: http://www.lesnikowski.com/blog/index.php/testing-datetime-now/

Resposta simples: vala System.DateTime :) Em vez disso, use o NodaTime e sua biblioteca de testes: NodaTime.Testing .

Leitura adicional:

• Teste de unidade com Noda Time
• Injeção de dependência: injete suas dependências, ponto final!

Você poderia injetar a classe (melhor: método / delegado ) para usar DateTime.Nowna classe que está sendo testada. Deve DateTime.Nowser um valor padrão e apenas configurá-lo no teste para um método fictício que retorna um valor constante.

EDIT: O que Blair Conrad disse (ele tem algum código para olhar). Exceto, eu tendo a preferir delegados para isso, já que eles não bagunçam sua hierarquia de classes com coisas como IClock...

Enfrentei essa situação com tanta frequência que criei um nuget simples que expõe a propriedade Now por meio da interface.

public interface IDateTimeTools
{
    DateTime Now { get; }
}

A implementação é, obviamente, muito simples

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

Depois de adicionar o nuget ao meu projeto, posso usá-lo nos testes de unidade

Você pode instalar o módulo diretamente do GUI Nuget Package Manager ou usando o comando:

Install-Package -Id DateTimePT -ProjectName Project

E o código do Nuget está aqui .

O exemplo de uso com o Autofac pode ser encontrado aqui .

Você já considerou o uso de compilação condicional para controlar o que acontece durante a depuração / implantação?

por exemplo

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

Caso contrário, você deseja expor a propriedade para que possa manipulá-la, tudo isso faz parte do desafio de escrever código testável , que é algo que estou lutando atualmente: D

Editar

Uma grande parte de mim preferiria a abordagem de Blair . Isso permite que você "conecte" partes do código para ajudar no teste. Tudo segue o princípio de design encapsular o que varia o código de teste não é diferente do código de produção, apenas ninguém o vê externamente.

A criação e a interface podem parecer muito trabalhosas para este exemplo (razão pela qual optei pela compilação condicional).