La mejor manera de usar temporizadores en .NET C#

Cómo tener control total sobre el temporizador y poder alcanzar el 100 % de cobertura con pruebas unitarias Al usar en su aplicación , es posible que tenga problemas para abstraerlo y poder cubrir sus módulos con pruebas unitarias. System.Timers.Timer .NET C# En este artículo, discutiremos las sobre cómo conquistar estos desafíos y, al final, podrá lograr una cobertura del 100 % de sus módulos. mejores prácticas El enfoque Así es como vamos a abordar nuestra solución: Piensa en un ejemplo muy simple para trabajar. Comience con la mala solución simple. Sigue intentando mejorarlo hasta que alcancemos el formato final. Resumiendo las lecciones aprendidas a lo largo de nuestro viaje. El ejemplo En nuestro ejemplo, crearemos una simple que solo haría una cosa simple: para escribir en la consola la . aplicación de consola usar System.Timers.Timer fecha y la hora cada segundo Al final, deberías terminar con esto: Como puede ver, es simple en términos de requisitos, nada lujoso. Descargo de responsabilidad Algunas prácticas recomendadas se ignorarían o eliminarían para centrar la atención principal en las otras prácticas recomendadas que se abordan en este artículo. En este artículo, nos centraremos en cubrir el módulo usando con pruebas unitarias. Sin embargo, el resto de la solución no se cubriría con pruebas unitarias. Si quieres saber más sobre esto, puedes consultar el artículo . System.Timers.Timer Cómo cubrir completamente la aplicación de consola .NET C# con pruebas unitarias Hay algunas bibliotecas de terceros que podrían usarse para lograr resultados casi similares. Sin embargo, siempre que sea posible, prefiero seguir un diseño nativo simple que depender de una gran biblioteca de terceros. Mala solución En esta solución, usaríamos directamente sin proporcionar una capa de abstracción. System.Timers.Timer La estructura de la solución debería verse así: Es una solución con solo un proyecto . de UsingTimer Console TimerApp Deliberadamente invertí algo de tiempo y esfuerzo en abstraer en para demostrar que esto no resolvería nuestro problema con el temporizador. System.Console IConsole namespace TimerApp.Abstractions { public interface IConsole { void WriteLine(object? value); } } Solo necesitaríamos usar en nuestro ejemplo; es por eso que este es el único método abstracto. System.Console.WriteLine namespace TimerApp.Abstractions { public interface IPublisher { void StartPublishing(); void StopPublishing(); } } Solo tenemos dos métodos en la interfaz : y . IPublisher StartPublishing StopPublishing Ahora, para las implementaciones: using TimerApp.Abstractions; namespace TimerApp.Implementations { public class Console : IConsole { public void WriteLine(object? value) { System.Console.WriteLine(value); } } } es solo una envoltura delgada para . 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); } } } es una implementación simple de . Está usando un y simplemente configurándolo. Publisher IPublisher System.Timers.Timer Tiene la definida como una dependencia. Esto no es una buena práctica desde mi punto de vista. Si quieres entender a lo que me refiero, puedes consultar el artículo . IConsole Cuándo no usar contenedores DI, IoC e IoC en .NET C# Sin embargo, solo por simplicidad, simplemente lo inyectaríamos como una dependencia en el constructor. También estamos configurando el intervalo del temporizador en 1000 milisegundos (1 segundo) y configurando el controlador para escribir Timer en la consola. 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(); } } } Aquí, en la clase , no estamos haciendo mucho. Solo estamos creando una instancia de la clase y comenzando a publicar. Program Publisher Ejecutar esto debería terminar con algo como esto: Ahora, la pregunta es, si va a escribir una prueba unitaria para la clase , ¿qué puede hacer? Publisher Desafortunadamente, la respuesta sería: . no demasiado Primero, no está inyectando el propio Timer como una dependencia. Esto significa que está ocultando la dependencia dentro de la clase . Por lo tanto, no podemos burlarnos o bloquear el temporizador. Publisher En segundo lugar, digamos que modificamos el código para que el temporizador ahora se inyecte en el constructor; aún así, la pregunta sería, ¿cómo escribir una prueba unitaria y reemplazar el temporizador con un simulacro o un resguardo? Escucho a alguien gritar, "envolvamos el Timer en una abstracción e inyectémoslo en lugar del Timer". Sí, así es, sin embargo, no es tan simple. Hay algunos trucos que voy a explicar en la siguiente sección. Buena solución Este es el momento de una buena solución. Veamos qué podemos hacer al respecto. La estructura de la solución debería verse así: Es la misma solución con un nuevo proyecto . de UsingTimer Console BetterTimerApp , y serían lo mismo. IConsole IPublisher Console Temporizador 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(); } } Lo que podemos notar aquí: Definimos el nuevo delegado . Este delegado representa el evento que generará nuestro . TimerIntervalElapsedEventHandler ITimer Puede argumentar que no necesitamos este nuevo delegado ya que tenemos el nativo que ya usa . ElapsedEventHandler System.Timers.Timer Sí, es cierto. Sin embargo, notará que el evento proporciona como argumentos del evento. Este tiene un constructor privado y no podría crear su propia instancia. Además, la propiedad definida en la clase es de solo lectura. Por lo tanto, no podrá anularlo en una clase secundaria. ElapsedEventHandler ElapsedEventArgs ElapsedEventArgs SignalTime ElapsedEventArgs Hay un ticket de solicitud de cambio abierto para que Microsoft actualice esta clase, pero hasta el momento de escribir este artículo, no se aplicaron cambios. Además, tenga en cuenta que extiende . ITimer IDisposable Editor 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); } } } Es casi igual que el antiguo excepto por pequeños cambios. Ahora, tenemos el definido como una dependencia que se inyecta a través del constructor. El resto del código sería el mismo. Publisher ITimer Temporizador 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); } } } Aquí es donde sucede casi toda la magia. Lo que podemos notar aquí: Internamente, estamos usando . System.Timers.Timer Aplicamos el patrón de diseño . Es por eso que puede ver el , , y . IDisposable private bool m_IsDisposed public void Dispose() protected virtual void Dispose(bool disposing) ~Timer() En el constructor, estamos inicializando una nueva instancia de . Nos referiremos a esto como el en el resto de los pasos. System.Timers.Timer temporizador interno Para , , y , solo estamos delegando la implementación al temporizador interno. public bool Enabled public double Interval public void Start() public void Stop() Para , esta es la parte más importante; así que vamos a analizarlo paso a paso. public event TimerIntervalElapsedEventHandler TimerIntervalElapsed Lo que tenemos que hacer con este evento es controlar cuándo alguien se suscribe o cancela su suscripción desde el exterior. En este caso, queremos reflejar esto en el temporizador interno. En otras palabras, si alguien externo tiene una instancia de nuestro , debería poder hacer algo como esto . ITimer t.TimerIntervalElapsed += (sender, dateTime) => { //do something } En este momento, lo que deberíamos hacer internamente es hacer algo como . m_Timer.Elapsed += (sender, elapsedEventArgs) => { //do something } Sin embargo, debemos tener en cuenta que los dos controladores no son iguales, ya que en realidad son de diferentes tipos; y . TimerIntervalElapsedEventHandler ElapsedEventHandler Por lo tanto, lo que debemos hacer es envolver el entrante en un nuevo interno. Esto es algo que podemos hacer. TimerIntervalElapsedEventHandler ElapsedEventHandler Sin embargo, también debemos tener en cuenta que, en algún momento, es posible que alguien deba cancelar la suscripción de un controlador del evento . TimerIntervalElapsedEventHandler Esto quiere decir que, en este momento, necesitamos poder saber qué manejador corresponde a ese manejador para poder darlo de baja del Temporizador Interno. ElapsedEventHandler TimerIntervalElapsedEventHandler La única forma de lograr esto es realizar un seguimiento de cada controlador y el controlador recién creado en un diccionario. De esta manera, al conocer el controlador pasado, podemos conocer el controlador correspondiente. TimerIntervalElapsedEventHandler ElapsedEventHandler TimerIntervalElapsedEventHandler ElapsedEventHandler Sin embargo, también debemos tener en cuenta que desde el exterior, alguien puede suscribirse al mismo controlador más de una vez. TimerIntervalElapsedEventHandler Sí, esto no es lógico, pero aun así, es factible. Por lo tanto, en aras de la exhaustividad, para cada controlador , mantendríamos una lista de controladores . TimerIntervalElapsedEventHandler ElapsedEventHandler En la mayoría de los casos, esta lista tendría una sola entrada a menos que se trate de una suscripción duplicada. Y es por eso que puede ver este . 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); } } } En el , estamos creando un nuevo , agregando un registro en , el diccionario lo asigna a y, finalmente, suscribiéndonos al temporizador interno. add ElapsedEventHandler m_Handlers TimerIntervalElapsedEventHandler En , obtenemos la lista correspondiente de controladores , seleccionamos el último controlador, cancelamos la suscripción del temporizador interno, lo eliminamos de la lista y eliminamos la entrada completa si la lista está vacía. remove ElapsedEventHandler También vale la pena mencionar la implementación . 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; } Estamos cancelando la suscripción de todos los controladores restantes del temporizador interno, eliminando el temporizador interno y borrando el diccionario . m_Handlers Programa 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(); } } } Aquí, todavía no estamos haciendo mucho. Es casi lo mismo que la solución anterior. Ejecutar esto debería terminar con algo como esto: Tiempo de prueba, el momento de la verdad Ahora, tenemos nuestro diseño final. Sin embargo, necesitamos ver si este diseño realmente puede ayudarnos a cubrir nuestro módulo con pruebas unitarias. Publisher La estructura de la solución debería verse así: Estoy usando y para probar. Seguro que puede trabajar con sus bibliotecas preferidas. NUnit Moq Temporizador 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; } } } Lo que podemos notar aquí: Definimos la enumeración que se usará al registrar las acciones realizadas a través de nuestro resguardo del temporizador. Esto se utilizaría más tarde para afirmar las acciones internas realizadas. Action Además, definimos la clase que se utilizará para el registro. ActionLog Definimos la clase como un stub de . Usaríamos este código auxiliar más tarde al probar el módulo . TimerStub ITimer Publisher La implementación es sencilla. Vale la pena mencionar que agregamos un método para que podamos activar el código auxiliar manualmente dentro de una prueba unitaria. public void TriggerTimerIntervalElapsed(DateTime dateTime) También podemos pasar el valor esperado de para que tengamos un valor conocido contra el cual afirmar. 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); } } } Ahora, como puede ver, tenemos el control total y podemos cubrir fácilmente nuestro módulo con pruebas unitarias. Publisher Si calculamos la cobertura, deberíamos obtener esto: Como puede ver, el módulo está 100% cubierto. Por lo demás, esto está fuera del alcance de este artículo, pero simplemente puede cubrirlo si sigue el enfoque del artículo. . Publisher Cómo cubrir completamente la aplicación de consola .NET C# con pruebas unitarias Ultimas palabras Puedes hacerlo. Es solo una cuestión de dividir módulos grandes en otros más pequeños, definir sus abstracciones, ser creativo con partes complicadas, y luego ya está. Si desea capacitarse más, puede consultar mis otros artículos sobre algunas mejores prácticas. Eso es todo, espero que hayas encontrado la lectura de este artículo tan interesante como yo encontré al escribirlo. También publicado aquí