Apa cara yang baik untuk menimpa DateTime.Now selama pengujian?

Saya punya beberapa kode (C #) yang bergantung pada tanggal hari ini untuk menghitung dengan benar berbagai hal di masa depan. Jika saya menggunakan tanggal hari ini dalam pengujian, saya harus mengulangi perhitungan dalam pengujian, yang rasanya tidak benar. Apa cara terbaik untuk menyetel tanggal ke nilai yang diketahui dalam pengujian sehingga saya dapat menguji bahwa hasilnya adalah nilai yang diketahui?

Preferensi saya adalah memiliki kelas yang menggunakan waktu sebenarnya bergantung pada antarmuka, seperti

interface IClock
{
    DateTime Now { get; } 
}

Dengan implementasi yang konkrit

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

Kemudian jika mau, Anda dapat menyediakan jenis jam lain yang Anda inginkan untuk pengujian, seperti

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

Mungkin ada beberapa overhead dalam menyediakan jam ke kelas yang bergantung padanya, tetapi itu dapat ditangani oleh sejumlah solusi injeksi ketergantungan (menggunakan wadah Pembalikan Kontrol, injeksi konstruktor / penyetel lama biasa, atau bahkan Pola Gerbang Statis ).

Mekanisme lain untuk mengirimkan objek atau metode yang menyediakan waktu yang diinginkan juga berfungsi, tetapi menurut saya kuncinya adalah menghindari menyetel ulang jam sistem, karena itu hanya akan menimbulkan rasa sakit di level lain.

Selain itu, menggunakan DateTime.Nowdan memasukkannya ke dalam kalkulasi Anda tidak hanya terasa tidak tepat - ini merampas kemampuan Anda untuk menguji waktu tertentu, misalnya jika Anda menemukan bug yang hanya terjadi di dekat batas tengah malam, atau pada hari Selasa. Menggunakan waktu saat ini tidak memungkinkan Anda untuk menguji skenario tersebut. Atau setidaknya tidak kapan pun Anda mau.

Ayende Rahien menggunakan metode statis yang cukup sederhana ...

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

Saya pikir membuat kelas jam terpisah untuk sesuatu yang sederhana seperti mendapatkan tanggal saat ini agak berlebihan.

Anda dapat melewatkan tanggal hari ini sebagai parameter sehingga Anda dapat memasukkan tanggal yang berbeda dalam pengujian. Ini memiliki keuntungan tambahan yaitu membuat kode Anda lebih fleksibel.

Menggunakan Microsoft Fakes untuk membuat shim adalah cara yang sangat mudah untuk melakukan ini. Misalkan saya memiliki kelas berikut:

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

}

Dalam Visual Studio 2012 Anda dapat menambahkan rakitan Fakes ke proyek pengujian Anda dengan mengklik kanan rakitan yang ingin Anda buat Fakes / Shims dan memilih "Add Fakes Assembly"

Terakhir, kelas pengujian akan terlihat seperti ini:

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

        }
    }
}
}

Kunci sukses unit testing adalah decoupling . Anda harus memisahkan kode yang menarik dari dependensi eksternalnya, sehingga dapat diuji secara terpisah. (Untungnya, Test-Driven Development menghasilkan kode terpisah.)

Dalam hal ini, eksternal Anda adalah DateTime saat ini.

Saran saya di sini adalah mengekstrak logika yang berhubungan dengan DateTime ke metode atau kelas baru atau apa pun yang masuk akal dalam kasus Anda, dan meneruskan DateTime masuk Sekarang, pengujian unit Anda dapat meneruskan DateTime sewenang-wenang, untuk menghasilkan hasil yang dapat diprediksi.

Yang lain menggunakan Microsoft Moles ( kerangka Isolasi untuk .NET ).

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

Moles memungkinkan untuk mengganti metode .NET apa pun dengan delegasi. Moles mendukung metode statis atau non-virtual. Tahi lalat bergantung pada profiler dari Pex.

Saya sarankan menggunakan pola 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);
    } 
}

Secara rinci dijelaskan di sini: http://www.lesnikowski.com/blog/index.php/testing-datetime-now/

Jawaban sederhana: parit System.DateTime :) Sebagai gantinya, gunakan NodaTime dan pustaka pengujiannya: NodaTime.Testing .

Bacaan lebih lanjut:

• Pengujian unit dengan Noda Time
• Injeksi Ketergantungan: Suntikkan Dependensi Anda, Titik!

Anda dapat memasukkan kelas (lebih baik: metode / delegasi ) yang Anda gunakan untuk DateTime.Nowdi kelas yang diuji. Telah DateTime.Nowmenjadi nilai default dan hanya mengaturnya dalam pengujian ke metode dummy yang mengembalikan nilai konstan.

EDIT: Apa yang dikatakan Blair Conrad (dia memiliki beberapa kode untuk dilihat). Kecuali, saya cenderung lebih suka delegasi untuk ini, karena mereka tidak mengacaukan hierarki kelas Anda dengan hal-hal seperti IClock...

Saya sering menghadapi situasi ini, sehingga saya membuat nuget sederhana yang mengekspos properti Now melalui antarmuka.

public interface IDateTimeTools
{
    DateTime Now { get; }
}

Penerapannya tentu saja sangat mudah

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

Jadi setelah menambahkan nuget ke proyek saya, saya dapat menggunakannya dalam pengujian unit

Anda dapat menginstal modul langsung dari GUI Nuget Package Manager atau dengan menggunakan perintah:

Install-Package -Id DateTimePT -ProjectName Project

Dan kode untuk Nuget ada di sini .

Contoh penggunaan dengan Autofac dapat ditemukan di sini .

Pernahkah Anda mempertimbangkan untuk menggunakan kompilasi bersyarat untuk mengontrol apa yang terjadi selama debug / penerapan?

misalnya

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

Jika gagal, Anda ingin mengekspos properti agar dapat memanipulasinya, ini semua adalah bagian dari tantangan menulis kode yang dapat diuji , yang saat ini sedang saya geluti sendiri: D

Edit

Sebagian besar dari diri saya lebih menyukai pendekatan Blair . Ini memungkinkan Anda untuk "menyambungkan" bagian kode untuk membantu pengujian. Itu semua mengikuti prinsip desain merangkum apa yang bervariasi kode uji tidak berbeda dengan kode produksi, hanya saja tidak ada yang pernah melihatnya secara eksternal.

Membuat dan antarmuka mungkin tampak seperti banyak pekerjaan untuk contoh ini meskipun (itulah sebabnya saya memilih kompilasi bersyarat).