Quel est un bon moyen de remplacer DateTime.Now pendant les tests?

J'ai du code (C #) qui s'appuie sur la date d'aujourd'hui pour calculer correctement les choses à l'avenir. Si j'utilise la date d'aujourd'hui dans le test, je dois répéter le calcul dans le test, ce qui ne me semble pas correct. Quelle est la meilleure façon de définir la date sur une valeur connue dans le test afin que je puisse tester que le résultat est une valeur connue?

Ma préférence est que les classes qui utilisent le temps reposent en fait sur une interface, telle que

interface IClock
{
    DateTime Now { get; } 
}

Avec une mise en œuvre concrète

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

Ensuite, si vous le souhaitez, vous pouvez fournir tout autre type d'horloge que vous souhaitez pour le test, tel que

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

Il peut y avoir une surcharge à fournir l'horloge à la classe qui en dépend, mais cela pourrait être géré par n'importe quel nombre de solutions d'injection de dépendances (en utilisant un conteneur d'inversion de contrôle, une ancienne injection de constructeur / setter, ou même un modèle de passerelle statique ).

D'autres mécanismes de livraison d'un objet ou d'une méthode qui fournit les heures souhaitées fonctionnent également, mais je pense que l'essentiel est d'éviter de réinitialiser l'horloge système, car cela ne fera qu'introduire de la douleur à d'autres niveaux.

De plus, l'utiliser DateTime.Nowet l'inclure dans vos calculs ne vous semble pas juste - cela vous prive de la possibilité de tester des moments particuliers, par exemple si vous découvrez un bogue qui ne se produit que près d'une limite de minuit ou le mardi. L'utilisation de l'heure actuelle ne vous permettra pas de tester ces scénarios. Ou du moins pas quand vous le souhaitez.

Ayende Rahien utilise une méthode statique assez simple ...

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

Je pense que créer une classe d'horloge séparée pour quelque chose de simple comme obtenir la date actuelle est un peu exagéré.

Vous pouvez transmettre la date du jour en tant que paramètre afin de pouvoir saisir une date différente dans le test. Cela présente l'avantage supplémentaire de rendre votre code plus flexible.

L'utilisation de Microsoft Fakes pour créer un shim est un moyen très simple de le faire. Supposons que j'ai eu le cours suivant:

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

}

Dans Visual Studio 2012, vous pouvez ajouter un assemblage Fakes à votre projet de test en cliquant avec le bouton droit sur l'assemblage pour lequel vous souhaitez créer Fakes / Shims et en sélectionnant «Ajouter un assemblage Fakes»

Enfin, voici à quoi ressemblerait la classe de 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 clé du succès des tests unitaires est le découplage . Vous devez séparer votre code intéressant de ses dépendances externes, afin qu'il puisse être testé isolément. (Heureusement, le développement piloté par les tests produit du code découplé.)

Dans ce cas, votre externe est le DateTime actuel.

Mon conseil ici est d'extraire la logique qui traite le DateTime vers une nouvelle méthode ou classe ou tout ce qui a du sens dans votre cas, et de passer le DateTime. Maintenant, votre test unitaire peut passer un DateTime arbitraire, pour produire des résultats prévisibles.

Un autre utilisant Microsoft Moles ( Isolation Framework for .NET ).

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

Moles permet de remplacer n'importe quelle méthode .NET par un délégué. Moles prend en charge les méthodes statiques ou non virtuelles. Moles s'appuie sur le profileur de Pex.

Je suggère d'utiliser le modèle 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 détail décrit ici: http://www.lesnikowski.com/blog/index.php/testing-datetime-now/

Réponse simple: abandonnez System.DateTime :) Au lieu de cela, utilisez NodaTime et sa bibliothèque de test: NodaTime.Testing .

Lectures complémentaires:

• Tests unitaires avec Noda Time
• Injection de dépendances: injectez vos dépendances, point final!

Vous pouvez injecter la classe (mieux: méthode / délégué ) que vous utilisez DateTime.Nowdans la classe testée. Avoir DateTime.Nowune valeur par défaut et ne la définir dans le test que sur une méthode factice qui renvoie une valeur constante.

EDIT: Ce que Blair Conrad a dit (il a du code à regarder). Sauf que j'ai tendance à préférer les délégués pour cela, car ils n'encombrent pas votre hiérarchie de classe avec des trucs comme IClock...

J'ai fait face à cette situation si souvent, que j'ai créé un simple nuget qui expose la propriété Now via l'interface.

public interface IDateTimeTools
{
    DateTime Now { get; }
}

La mise en œuvre est bien sûr très simple

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

Donc, après avoir ajouté nuget à mon projet, je peux l'utiliser dans les tests unitaires

Vous pouvez installer le module directement à partir du gestionnaire de packages GUI Nuget ou en utilisant la commande:

Install-Package -Id DateTimePT -ProjectName Project

Et le code pour le Nuget est ici .

L'exemple d'utilisation avec l'Autofac peut être trouvé ici .

Avez-vous envisagé d'utiliser la compilation conditionnelle pour contrôler ce qui se passe pendant le débogage / le déploiement?

par exemple

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

À défaut, vous voulez exposer la propriété afin de pouvoir la manipuler, tout cela fait partie du défi d'écrire du code testable , ce que je lutte moi-même actuellement: D

Éditer

Une grande partie de moi préférerait l'approche de Blair . Cela vous permet de «connecter à chaud» des parties du code pour faciliter les tests. Tout suit le principe de conception: encapsuler ce qui varie le code de test n'est pas différent du code de production, c'est juste que personne ne le voit jamais de l'extérieur.

La création et l'interface peuvent sembler beaucoup de travail pour cet exemple (c'est pourquoi j'ai opté pour la compilation conditionnelle).