Der beste Weg, Timer in .NET C# zu verwenden

So haben Sie die volle Kontrolle über den Timer und können mit Unit-Tests eine 100-prozentige Abdeckung erreichen Wenn Sie in Ihrer -Anwendung verwenden, treten möglicherweise Probleme bei der Abstraktion und der Möglichkeit auf, Ihre Module mit Komponententests abzudecken. System.Timers.Timer .NET C# In diesem Artikel diskutieren wir die , wie Sie diese Herausforderungen meistern können, und am Ende werden Sie in der Lage sein, eine 100-prozentige Abdeckung Ihrer Module zu erreichen. Best Practices Die Vorgehensweise So gehen wir unsere Lösung an: Überlegen Sie sich ein sehr einfaches Beispiel, an dem Sie arbeiten können. Beginnen Sie mit der einfachen schlechten Lösung. Versuchen Sie weiter, es zu verbessern, bis wir das endgültige Format erreicht haben. Zusammenfassung der Erkenntnisse unserer Reise. Das Beispiel In unserem Beispiel erstellen wir eine einfache , die nur eine einfache Sache tun würde: , um in die Konsole zu schreiben. Konsolenanwendung Verwenden Sie einen System.Timers.Timer jede Sekunde Datum und Uhrzeit Am Ende sollten Sie Folgendes erhalten: Wie Sie sehen, sind die Anforderungen einfach, nichts Besonderes. Haftungsausschluss Einige Best Practices werden ignoriert/verworfen, um den Schwerpunkt auf die anderen Best Practices zu lenken, auf die in diesem Artikel abzielt. In diesem Artikel konzentrieren wir uns darauf, das Modul mithilfe von mit Komponententests abzudecken. Der Rest der Lösung würde jedoch nicht durch Unit-Tests abgedeckt. Wenn Sie mehr darüber erfahren möchten, können Sie den Artikel lesen . System.Timers.Timer So decken Sie die .NET C#-Konsolenanwendung vollständig mit Komponententests ab Es gibt einige Bibliotheken von Drittanbietern, mit denen sich nahezu ähnliche Ergebnisse erzielen lassen. Allerdings würde ich, wann immer möglich, lieber einem nativen, einfachen Design folgen, als mich auf eine ganze große Bibliothek eines Drittanbieters zu verlassen. Schlechte Lösung In dieser Lösung würden wir direkt verwenden, ohne eine Abstraktionsebene bereitzustellen. System.Timers.Timer Der Aufbau der Lösung sollte wie folgt aussehen: Es handelt sich um eine Lösung mit nur einem Projekt. UsingTimer- Console TimerApp- Ich habe absichtlich etwas Zeit und Mühe in die Abstraktion in investiert, um zu beweisen, dass dies unser Problem mit dem Timer nicht lösen würde. System.Console IConsole namespace TimerApp.Abstractions { public interface IConsole { void WriteLine(object? value); } } In unserem Beispiel müssten wir nur verwenden; Deshalb ist dies die einzige abstrahierte Methode. System.Console.WriteLine namespace TimerApp.Abstractions { public interface IPublisher { void StartPublishing(); void StopPublishing(); } } Wir haben nur zwei Methoden auf der Schnittstelle: und . IPublisher StartPublishing StopPublishing Nun zu den Implementierungen: using TimerApp.Abstractions; namespace TimerApp.Implementations { public class Console : IConsole { public void WriteLine(object? value) { System.Console.WriteLine(value); } } } ist nur ein dünner Wrapper für . Console System.Console using System.Timers; using TimerApp.Abstractions; namespace TimerApp.Implementations { public class Publisher : IPublisher { private readonly Timer m_Timer; private readonly IConsole m_Console; public Publisher(IConsole console) { m_Timer = new Timer(); m_Timer.Enabled = true; m_Timer.Interval = 1000; m_Timer.Elapsed += Handler; m_Console = console; } public void StartPublishing() { m_Timer.Start(); } public void StopPublishing() { m_Timer.Stop(); } private void Handler(object sender, ElapsedEventArgs args) { m_Console.WriteLine(args.SignalTime); } } } ist eine einfache Implementierung von . Es verwendet einen und konfiguriert ihn nur. Publisher IPublisher System.Timers.Timer Die ist als Abhängigkeit definiert. Dies ist aus meiner Sicht keine Best Practice. Wenn Sie verstehen möchten, was ich meine, können Sie den Artikel lesen . IConsole Wann DI-, IoC- und IoC-Container in .NET C# nicht verwendet werden sollten Der Einfachheit halber würden wir es jedoch einfach als Abhängigkeit in den Konstruktor einfügen. Wir setzen außerdem das Timer-Intervall auf 1000 Millisekunden (1 Sekunde) und stellen den Handler so ein, dass er die Timer- in die Konsole schreibt. SignalTime using TimerApp.Abstractions; using TimerApp.Implementations; namespace TimerApp { public class Program { static void Main(string[] args) { IPublisher publisher = new Publisher(new Implementations.Console()); publisher.StartPublishing(); System.Console.ReadLine(); publisher.StopPublishing(); } } } Hier in der machen wir nicht viel. Wir erstellen gerade eine Instanz der Klasse und beginnen mit der Veröffentlichung. Program Publisher Wenn Sie dies ausführen, sollte dies etwa so aussehen: Die Frage ist nun: Was können Sie tun, wenn Sie einen Komponententest für die Klasse schreiben möchten? Publisher Leider wäre die Antwort: . nicht zu viel Erstens fügen Sie den Timer selbst nicht als Abhängigkeit ein. Das bedeutet, dass Sie die Abhängigkeit innerhalb der Klasse verbergen. Daher können wir den Timer nicht verspotten oder stoppen. Publisher Nehmen wir zweitens an, dass wir den Code so geändert haben, dass der Timer jetzt in den Konstruktor eingefügt wird. Dennoch wäre die Frage, wie man einen Unit-Test schreibt und den Timer durch einen Mock oder Stub ersetzt. Ich höre jemanden schreien: „Lasst uns den Timer in eine Abstraktion einbinden und ihn anstelle des Timers einfügen.“ Ja, das stimmt, allerdings ist es nicht so einfach. Es gibt einige Tricks, die ich im nächsten Abschnitt erklären werde. Gute Lösung Jetzt ist die Zeit für eine gute Lösung. Mal sehen, was wir dagegen tun können. Der Aufbau der Lösung sollte wie folgt aussehen: Es handelt sich um die gleiche Lösung mit einem neuen Projekt. UsingTimer- Console BetterTimerApp- , und wären identisch. IConsole IPublisher Console ITimer using System; namespace BetterTimerApp.Abstractions { public delegate void TimerIntervalElapsedEventHandler(object sender, DateTime dateTime); public interface ITimer : IDisposable { event TimerIntervalElapsedEventHandler TimerIntervalElapsed; bool Enabled { get; set; } double Interval { get; set; } void Start(); void Stop(); } } Was wir hier bemerken können: Wir haben den neuen Delegaten definiert. Dieser Delegat stellt das Ereignis dar, das von unserem ausgelöst werden soll. TimerIntervalElapsedEventHandler ITimer Sie könnten argumentieren, dass wir diesen neuen Delegaten nicht benötigen, da wir bereits über den nativen verfügen, der bereits von verwendet wird. ElapsedEventHandler System.Timers.Timer Ja, das stimmt. Sie werden jedoch feststellen, dass das Ereignis als Ereignisargumente bereitstellt. Dieses verfügt über einen privaten Konstruktor und Sie könnten keine eigene Instanz erstellen. Darüber hinaus ist die in der -Klasse definierte Eigenschaft schreibgeschützt. Daher können Sie es in einer untergeordneten Klasse nicht überschreiben. ElapsedEventHandler ElapsedEventArgs ElapsedEventArgs ElapsedEventArgs SignalTime Für Microsoft wurde ein Änderungsanforderungsticket zur Aktualisierung dieser Klasse geöffnet, aber bis zum Zeitpunkt der Erstellung dieses Artikels wurden keine Änderungen vorgenommen. Beachten Sie außerdem, dass das erweitert. ITimer IDisposable Herausgeber using System; using BetterTimerApp.Abstractions; namespace BetterTimerApp.Implementations { public class Publisher : IPublisher { private readonly ITimer m_Timer; private readonly IConsole m_Console; public Publisher(ITimer timer, IConsole console) { m_Timer = timer; m_Timer.Enabled = true; m_Timer.Interval = 1000; m_Timer.TimerIntervalElapsed += Handler; m_Console = console; } public void StartPublishing() { m_Timer.Start(); } public void StopPublishing() { m_Timer.Stop(); } private void Handler(object sender, DateTime dateTime) { m_Console.WriteLine(dateTime); } } } Bis auf kleine Änderungen ist es fast identisch mit dem alten . Jetzt haben wir den als Abhängigkeit definiert, die über den Konstruktor eingefügt wird. Der Rest des Codes wäre derselbe. Publisher ITimer Timer using System; using System.Collections.Generic; using System.Linq; using System.Timers; using BetterTimerApp.Abstractions; namespace BetterTimerApp.Implementations { public class Timer : ITimer { private Dictionary > m_Handlers = new(); private bool m_IsDisposed; private System.Timers.Timer m_Timer; public Timer() { m_Timer = new System.Timers.Timer(); } public event TimerIntervalElapsedEventHandler TimerIntervalElapsed { add { var internalHandler = (ElapsedEventHandler)((sender, args) => { value.Invoke(sender, args.SignalTime); }); if (!m_Handlers.ContainsKey(value)) { m_Handlers.Add(value, new List ()); } m_Handlers[value].Add(internalHandler); m_Timer.Elapsed += internalHandler; } remove { m_Timer.Elapsed -= m_Handlers[value].Last(); m_Handlers[value].RemoveAt(m_Handlers[value].Count - 1); if (!m_Handlers[value].Any()) { m_Handlers.Remove(value); } } } public bool Enabled { get => m_Timer.Enabled; set => m_Timer.Enabled = value; } public double Interval { get => m_Timer.Interval; set => m_Timer.Interval = value; } public void Start() { m_Timer.Start(); } public void Stop() { m_Timer.Stop(); } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected virtual void Dispose(bool disposing) { if (m_IsDisposed) return; if (disposing && m_Handlers.Any()) { foreach (var internalHandlers in m_Handlers.Values) { if (internalHandlers?.Any() ?? false) { internalHandlers.ForEach(handler => m_Timer.Elapsed -= handler); } } m_Timer.Dispose(); m_Timer = null; m_Handlers.Clear(); m_Handlers = null; } m_IsDisposed = true; } ~Timer() { Dispose(false); } } } Hier passiert fast die ganze Magie. Was wir hier bemerken können: Intern verwenden wir . System.Timers.Timer Wir haben das Designmuster angewendet. Aus diesem Grund können Sie den , , und den sehen. IDisposable- private bool m_IsDisposed public void Dispose() protected virtual void Dispose(bool disposing) ~Timer() Im Konstruktor initialisieren wir eine neue Instanz von . Wir würden dies in den restlichen Schritten als bezeichnen. System.Timers.Timer internen Timer Für , , und delegieren wir lediglich die Implementierung an den internen Timer. public bool Enabled public double Interval public void Start() public void Stop() Für ist dies der wichtigste Teil; Lassen Sie es uns also Schritt für Schritt analysieren. public event TimerIntervalElapsedEventHandler TimerIntervalElapsed Was wir mit diesem Ereignis tun müssen, ist zu handhaben, wenn jemand es von außerhalb abonniert/abbestellt. In diesem Fall möchten wir dies auf den internen Timer spiegeln. Mit anderen Worten: Wenn jemand von außerhalb eine Instanz unseres hat, sollte er in der Lage sein, so etwas zu tun . ITimer t.TimerIntervalElapsed += (sender, dateTime) => { //do something } Was wir in diesem Moment tun sollten, ist intern etwas wie . m_Timer.Elapsed += (sender, elapsedEventArgs) => { //do something } Wir müssen jedoch bedenken, dass die beiden Handler nicht identisch sind, da sie tatsächlich unterschiedlichen Typs sind; und . TimerIntervalElapsedEventHandler ElapsedEventHandler Daher müssen wir den kommenden in einen neuen internen einschließen. Das können wir tun. TimerIntervalElapsedEventHandler ElapsedEventHandler Allerdings müssen wir auch bedenken, dass irgendwann jemand einen Handler vom -Ereignis abmelden muss. TimerIntervalElapsedEventHandler Das bedeutet, dass wir in diesem Moment wissen müssen, welcher Handler diesem Handler entspricht, damit wir ihn vom internen Timer abmelden können. ElapsedEventHandler TimerIntervalElapsedEventHandler Die einzige Möglichkeit, dies zu erreichen, besteht darin, jeden -Handler und den neu erstellten Handler in einem Wörterbuch zu verfolgen. Auf diese Weise können wir durch Kenntnis des übergebenen Handlers den entsprechenden Handler kennen. TimerIntervalElapsedEventHandler ElapsedEventHandler TimerIntervalElapsedEventHandler ElapsedEventHandler Wir müssen jedoch auch bedenken, dass jemand von außen möglicherweise denselben Handler mehr als einmal abonniert. TimerIntervalElapsedEventHandler Ja, das ist nicht logisch, aber dennoch machbar. Der Vollständigkeit halber würden wir daher für jeden Handler eine Liste der Handler führen. TimerIntervalElapsedEventHandler ElapsedEventHandler In den meisten Fällen enthält diese Liste nur einen Eintrag, es sei denn, es handelt sich um ein doppeltes Abonnement. Und deshalb können Sie dieses sehen. . private Dictionary > m_Handlers = new(); public event TimerIntervalElapsedEventHandler TimerIntervalElapsed { add { var internalHandler = (ElapsedEventHandler)((sender, args) => { value.Invoke(sender, args.SignalTime); }); if (!m_Handlers.ContainsKey(value)) { m_Handlers.Add(value, new List ()); } m_Handlers[value].Add(internalHandler); m_Timer.Elapsed += internalHandler; } remove { m_Timer.Elapsed -= m_Handlers[value].Last(); m_Handlers[value].RemoveAt(m_Handlers[value].Count - 1); if (!m_Handlers[value].Any()) { m_Handlers.Remove(value); } } } Im erstellen wir einen neuen , fügen einen Datensatz im Wörterbuch hinzu, der diesen zuordnet, und abonnieren schließlich den internen Timer. add ElapsedEventHandler m_Handlers TimerIntervalElapsedEventHandler In „ rufen wir die entsprechende Liste der Handler ab, wählen den letzten Handler aus, melden ihn vom internen Timer ab, entfernen ihn aus der Liste und entfernen den gesamten Eintrag, wenn die Liste leer ist. remove ElapsedEventHandler Erwähnenswert ist auch die Implementierung. Dispose protected virtual void Dispose(bool disposing) { if (m_IsDisposed) return; if (disposing && m_Handlers.Any()) { foreach (var internalHandlers in m_Handlers.Values) { if (internalHandlers?.Any() ?? false) { internalHandlers.ForEach(handler => m_Timer.Elapsed -= handler); } } m_Timer.Dispose(); m_Timer = null; m_Handlers.Clear(); m_Handlers = null; } m_IsDisposed = true; } Wir melden alle verbleibenden Handler vom internen Timer ab, entsorgen den internen Timer und löschen das Wörterbuch. m_Handlers Programm using BetterTimerApp.Abstractions; using BetterTimerApp.Implementations; namespace BetterTimerApp { public class Program { static void Main(string[] args) { var timer = new Timer(); IPublisher publisher = new Publisher(timer, new Implementations.Console()); publisher.StartPublishing(); System.Console.ReadLine(); publisher.StopPublishing(); timer.Dispose(); } } } Hier tun wir noch nicht viel. Es ist fast das Gleiche wie die alte Lösung. Wenn Sie dies ausführen, sollte dies etwa so aussehen: Zeit zum Testen, der Moment der Wahrheit Jetzt haben wir unser endgültiges Design. Wir müssen jedoch sehen, ob dieses Design uns wirklich dabei helfen kann, unser Modul mit Unit-Tests abzudecken. Publisher Der Aufbau der Lösung sollte wie folgt aussehen: Ich verwende und zum Testen. Sie können sicher mit Ihren bevorzugten Bibliotheken arbeiten. NUnit Moq TimerStub using System; using System.Collections.Generic; using BetterTimerApp.Abstractions; namespace BetterTimerApp.Tests.Stubs { public enum Action { Start = 1, Stop = 2, Triggered = 3, Enabled = 4, Disabled = 5, IntervalSet = 6 } public class ActionLog { public Action Action { get; } public string Message { get; } public ActionLog(Action action, string message) { Action = action; Message = message; } } public class TimerStub : ITimer { private bool m_Enabled; private double m_Interval; public event TimerIntervalElapsedEventHandler TimerIntervalElapsed; public Dictionary Log = new(); public bool Enabled { get => m_Enabled; set { m_Enabled = value; Log.Add(Log.Count + 1, new ActionLog(value ? Action.Enabled : Action.Disabled, value ? "Enabled" : "Disabled")); } } public double Interval { get => m_Interval; set { m_Interval = value; Log.Add(Log.Count + 1, new ActionLog(Action.IntervalSet, m_Interval.ToString("G17"))); } } public void Start() { Log.Add(Log.Count + 1, new ActionLog(Action.Start, "Started")); } public void Stop() { Log.Add(Log.Count + 1, new ActionLog(Action.Stop, "Stopped")); } public void TriggerTimerIntervalElapsed(DateTime dateTime) { OnTimerIntervalElapsed(dateTime); Log.Add(Log.Count + 1, new ActionLog(Action.Triggered, "Triggered")); } protected void OnTimerIntervalElapsed(DateTime dateTime) { TimerIntervalElapsed?.Invoke(this, dateTime); } public void Dispose() { Log.Clear(); Log = null; } } } Was wir hier bemerken können: Wir haben die definiert, die beim Protokollieren der über unseren Timer-Stub durchgeführten Aktionen verwendet werden soll. Dies würde später verwendet werden, um die durchgeführten internen Aktionen geltend zu machen. Action Außerdem haben wir die Klasse definiert, die für die Protokollierung verwendet werden soll. ActionLog Wir haben die Klasse als Stub von definiert. Wir würden diesen Stub später beim Testen des Moduls verwenden. TimerStub ITimer Publisher Die Umsetzung ist einfach. Erwähnenswert ist, dass wir eine zusätzliche hinzugefügt haben, damit wir den Stub innerhalb eines Komponententests manuell auslösen können. public void TriggerTimerIntervalElapsed(DateTime dateTime) Wir können auch den erwarteten Wert von übergeben, sodass wir einen bekannten Wert haben, gegen den wir behaupten können. dateTime PublisherTests using System; using BetterTimerApp.Abstractions; using BetterTimerApp.Implementations; using BetterTimerApp.Tests.Stubs; using Moq; using NUnit.Framework; using Action = BetterTimerApp.Tests.Stubs.Action; namespace BetterTimerApp.Tests.Tests { [TestFixture] public class PublisherTests { private TimerStub m_TimerStub; private Mock m_ConsoleMock; private Publisher m_Sut; [SetUp] public void SetUp() { m_TimerStub = new TimerStub(); m_ConsoleMock = new Mock (); m_Sut = new Publisher(m_TimerStub, m_ConsoleMock.Object); } [TearDown] public void TearDown() { m_Sut = null; m_ConsoleMock = null; m_TimerStub = null; } [Test] public void ConstructorTest() { Assert.AreEqual(Action.Enabled, m_TimerStub.Log[1].Action); Assert.AreEqual(Action.Enabled.ToString(), m_TimerStub.Log[1].Message); Assert.AreEqual(Action.IntervalSet, m_TimerStub.Log[2].Action); Assert.AreEqual(1000.ToString("G17"), m_TimerStub.Log[2].Message); } [Test] public void StartPublishingTest() { // Arrange var expectedDateTime = DateTime.Now; m_ConsoleMock .Setup ( m => m.WriteLine ( It.Is (p => p == expectedDateTime) ) ) .Verifiable(); // Act m_Sut.StartPublishing(); m_TimerStub.TriggerTimerIntervalElapsed(expectedDateTime); // Assert ConstructorTest(); m_ConsoleMock .Verify ( m => m.WriteLine(expectedDateTime) ); Assert.AreEqual(Action.Start, m_TimerStub.Log[3].Action); Assert.AreEqual("Started", m_TimerStub.Log[3].Message); Assert.AreEqual(Action.Triggered, m_TimerStub.Log[4].Action); Assert.AreEqual(Action.Triggered.ToString(), m_TimerStub.Log[4].Message); } [Test] public void StopPublishingTest() { // Act m_Sut.StopPublishing(); // Assert ConstructorTest(); Assert.AreEqual(Action.Stop, m_TimerStub.Log[3].Action); Assert.AreEqual("Stopped", m_TimerStub.Log[3].Message); } [Test] public void FullProcessTest() { // Arrange var expectedDateTime1 = DateTime.Now; var expectedDateTime2 = expectedDateTime1 + TimeSpan.FromSeconds(1); var expectedDateTime3 = expectedDateTime2 + TimeSpan.FromSeconds(1); var sequence = new MockSequence(); m_ConsoleMock .InSequence(sequence) .Setup ( m => m.WriteLine ( It.Is (p => p == expectedDateTime1) ) ) .Verifiable(); m_ConsoleMock .InSequence(sequence) .Setup ( m => m.WriteLine ( It.Is (p => p == expectedDateTime2) ) ) .Verifiable(); m_ConsoleMock .InSequence(sequence) .Setup ( m => m.WriteLine ( It.Is (p => p == expectedDateTime3) ) ) .Verifiable(); // Act m_Sut.StartPublishing(); m_TimerStub.TriggerTimerIntervalElapsed(expectedDateTime1); // Assert ConstructorTest(); m_ConsoleMock .Verify ( m => m.WriteLine(expectedDateTime1) ); Assert.AreEqual(Action.Start, m_TimerStub.Log[3].Action); Assert.AreEqual("Started", m_TimerStub.Log[3].Message); Assert.AreEqual(Action.Triggered, m_TimerStub.Log[4].Action); Assert.AreEqual(Action.Triggered.ToString(), m_TimerStub.Log[4].Message); // Act m_TimerStub.TriggerTimerIntervalElapsed(expectedDateTime2); // Assert m_ConsoleMock .Verify ( m => m.WriteLine(expectedDateTime2) ); Assert.AreEqual(Action.Triggered, m_TimerStub.Log[5].Action); Assert.AreEqual(Action.Triggered.ToString(), m_TimerStub.Log[5].Message); // Act m_Sut.StopPublishing(); // Assert Assert.AreEqual(Action.Stop, m_TimerStub.Log[6].Action); Assert.AreEqual("Stopped", m_TimerStub.Log[6].Message); } } } Wie Sie sehen, haben wir jetzt die volle Kontrolle und können unser Modul problemlos mit Unit-Tests abdecken. Publisher Wenn wir die Abdeckung berechnen, sollten wir Folgendes erhalten: Wie Sie sehen, ist das Modul zu 100 % abgedeckt. Im Übrigen ist dies nicht Gegenstand dieses Artikels, aber Sie können es einfach behandeln, wenn Sie dem Ansatz im Artikel folgen . Publisher So decken Sie die .NET C#-Konsolenanwendung vollständig mit Komponententests ab Letzte Worte Du kannst es schaffen. Es geht lediglich darum, große Module in kleinere aufzuteilen, Ihre Abstraktionen zu definieren, bei kniffligen Teilen kreativ zu werden, und schon sind Sie fertig. Wenn Sie sich weiterbilden möchten, können Sie sich meine anderen Artikel über einige Best Practices ansehen. Ich hoffe, Sie fanden die Lektüre dieses Artikels genauso interessant wie ich das Schreiben. Auch veröffentlicht hier