Qual è un buon modo per sovrascrivere DateTime.Now durante il test?

Ho del codice (C #) che si basa sulla data odierna per calcolare correttamente le cose in futuro. Se uso la data odierna nel test, devo ripetere il calcolo nel test, il che non sembra corretto. Qual è il modo migliore per impostare la data su un valore noto all'interno del test in modo da poter verificare che il risultato sia un valore noto?

La mia preferenza è che le classi che utilizzano il tempo si basino effettivamente su un'interfaccia, come

interface IClock
{
    DateTime Now { get; } 
}

Con un'implementazione concreta

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

Quindi, se lo desideri, puoi fornire qualsiasi altro tipo di orologio che desideri per il test, come

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

Potrebbe esserci un sovraccarico nel fornire l'orologio alla classe che si basa su di esso, ma ciò potrebbe essere gestito da un numero qualsiasi di soluzioni di inserimento delle dipendenze (utilizzando un contenitore di inversione del controllo, una semplice vecchia iniezione di costruttore / setter o persino un modello di gateway statico ).

Funzionano anche altri meccanismi per fornire un oggetto o un metodo che fornisce i tempi desiderati, ma penso che la cosa fondamentale sia evitare di ripristinare l'orologio di sistema, poiché questo introdurrà dolore su altri livelli.

Inoltre, utilizzarlo DateTime.Nowe includerlo nei tuoi calcoli non solo non ti sembra giusto, ma ti priva della capacità di testare orari particolari, ad esempio se scopri un bug che si verifica solo vicino a un confine di mezzanotte o il martedì. L'utilizzo dell'ora corrente non ti consentirà di testare questi scenari. O almeno non quando vuoi.

Ayende Rahien utilizza un metodo statico piuttosto semplice ...

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

Penso che creare una classe di clock separata per qualcosa di semplice come ottenere la data corrente sia un po 'eccessivo.

Puoi passare la data odierna come parametro in modo da poter inserire una data diversa nel test. Questo ha l'ulteriore vantaggio di rendere il tuo codice più flessibile.

Usare Microsoft Fakes per creare uno shim è un modo davvero semplice per farlo. Supponiamo di avere la seguente classe:

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

}

In Visual Studio 2012 è possibile aggiungere un assembly Fakes al progetto di test facendo clic con il pulsante destro del mouse sull'assembly per cui si desidera creare Fakes / Shim e selezionando "Add Fakes Assembly"

Infine, ecco come sarebbe la classe di test:

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 chiave per un test unitario di successo è il disaccoppiamento . Devi separare il tuo codice interessante dalle sue dipendenze esterne, in modo che possa essere testato isolatamente. (Fortunatamente, Test-Driven Development produce codice disaccoppiato.)

In questo caso, il tuo esterno è il DateTime corrente.

Il mio consiglio qui è di estrarre la logica che si occupa del DateTime in un nuovo metodo o classe o qualsiasi altra cosa abbia senso nel tuo caso e passare il DateTime. Ora, il tuo unit test può passare un DateTime arbitrario, per produrre risultati prevedibili.

Un altro che utilizza Microsoft Moles ( framework di isolamento per .NET ).

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

Moles consente di sostituire qualsiasi metodo .NET con un delegato. Le talpe supportano metodi statici o non virtuali. Moles si affida al profiler di Pex.

Suggerirei di utilizzare il pattern 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);
    } 
}

In dettaglio descritto qui: http://www.lesnikowski.com/blog/index.php/testing-datetime-now/

Risposta semplice: ditch System.DateTime :) Invece, usa NodaTime e la sua libreria di test: NodaTime.Testing .

Ulteriore lettura:

• Test unitario con Noda Time
• Iniezione di dipendenze: inietta le tue dipendenze, punto!

Potresti iniettare la classe (meglio: metodo / delegato ) che usi per DateTime.Nowla classe in esame. Devono DateTime.Nowessere un valore predefinito e impostarlo solo in testing su un metodo fittizio che restituisce un valore costante.

MODIFICARE: Quello che ha detto Blair Conrad (ha del codice da guardare). Tranne, tendo a preferire i delegati per questo, poiché non ingombrano la tua gerarchia di classe con cose come IClock...

Ho affrontato questa situazione così spesso, che ho creato un semplice nuget che espone la proprietà Now tramite l'interfaccia.

public interface IDateTimeTools
{
    DateTime Now { get; }
}

L'implementazione è ovviamente molto semplice

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

Quindi, dopo aver aggiunto nuget al mio progetto, posso usarlo negli unit test

È possibile installare il modulo direttamente dalla GUI Nuget Package Manager o utilizzando il comando:

Install-Package -Id DateTimePT -ProjectName Project

E il codice per il Nuget è qui .

L'esempio di utilizzo con l'Autofac può essere trovato qui .

Hai considerato l'utilizzo della compilazione condizionale per controllare cosa accade durante il debug / la distribuzione?

per esempio

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

In caso contrario, vuoi esporre la proprietà in modo da poterla manipolare, tutto questo fa parte della sfida di scrivere codice testabile , che è qualcosa che sto attualmente lottando da solo: D

modificare

Gran parte di me preferirebbe l'approccio di Blair . Ciò consente di "collegare a caldo" parti del codice per facilitare i test. Tutto segue il principio di progettazione che racchiude ciò che varia codice di test non è diverso dal codice di produzione, è solo che nessuno lo vede mai esternamente.

La creazione e l'interfaccia possono sembrare un sacco di lavoro per questo esempio (motivo per cui ho optato per la compilazione condizionale).