Lucas Ontivero : Patrones, Desarrollo, TDD

¿Vale la pena crear pruebas unitarias?

Lucas Ontivero — Thu, 31 Mar 2011 16:19:43 GMT

La creación de pruebas unitarias requiere al menos lo siguiente:

Un framework de pruebas unitarias que debemos dominar. Por lo general son muy simples.
Código testeable. Típicamente esto implica código susceptible de ser “aislado”.

Nada que decir con respecto al primer punto. Ahora, en cuanto al segundo punto, ¿qué significa que el código pueda ser “aislado”?. Bueno, esto significa que sus dependencias deben poder ser reemplazadas. Esto lo logramos bien por medio de inyectarle sus dependencias o bien utilizando un patrón ServiceLocator (a algún framework con un contenedor de dependencias).

Entonces, una vez resuelto, necesitamos proveer al código objeto de prueba, dependencias “falsas”. Esto nuevamente requiere o bien que las creemos a manos o que utilicemos algún isolation framework para crearlas (por lo general en runtime).

Hasta ahora nada que no sepamos todos ¿verdad? Pero… ¡Vamos de nuevo! Veámoslo en código por favor. Imaginemos que tenemos el siguiente método pero no podemos probarlo porque su dependencia con el LogHelper (una clase con métodos estáticos) nos lo impiden:

     public class TransferManager

    {

        public void Tranfer(Account from, Account to, Money amount)

        {

            // Perform the required actions

            LogHelper.Inform("Done!");

        }

    }

Si no quisiéramos enredarnos mucho, lo que haríamos sería algo como lo que sigue:

    public class TransferManager

    {

        private readonly ILogger _logger;

        public TransferManager(ILogger logger)

        {

            this._logger = logger;

        }

        public void Tranfer(Account from, Account to, Money amount)

        {

            // Perform the required actions

            _logger.Inform("Done!");

        }

    }

Y la prueba, se parecería a lo que sigue:

    [TestMethod]

    public void Perform_a_valid_tranfer()

    {

        var aFakeLogger = new FakeLogger();

        var tranferManager = new TransferManager(aFakeLogger);

        // Do and Assert here

    }

Lo que falta:

    interface ILogger

    {

        void Inform(string messageToLog);

    }

    class FakeLogger : ILogger

    {

        public void  Inform(string messageToLog)

        {

            // Nothing to do

        }

    }

¿Que debimos hacer para probar esa pieza de código? Bueno, varias cosas: en primer lugar fue necesario crear una interface hasta el momento innecesaria (ILogger), tuvimos que agregar un constructor para inyectarle esta dependencia juntamente con un campo para almacenarla; debimos además, y aunque no se muestre aquí, hacer un wrapper para el LogHelper que implemente la interface ILogger. Por otro lado, en el proyecto de prueba, debimos crear una clase falsa (la FakeLogger).

Creamos FakeLogger de manera manual y con su implementación más sencilla (no hace absolutamente nada) pero bien podríamos haberla creado con un framework de aislamiento y especificarle algún comportamiento.

Es decir que el código es ahora más complejo que antes ya que tiene, al menos en este ejemplo, un campo más (_logger), un constructor más, una interface más (la ILogger) y una clase más (el wrapper del LogHelper). El código que crea una instancia de esta clase (TranferManager) también se ve afectado. Este es el costo que lleva asociado ineludiblemente el probar, mediante pruebas unitarias, cualquier código.

Claro, la pregunta es: ¿Valdrá la pena?

Compiler as a Service – Parte 2

Lucas Ontivero — Tue, 22 Feb 2011 18:34:46 GMT

Si el compilador de C# pudiera utilizarse como cualquier assembly, podríamos generar código y compilarlo en tiempo de ejecución. Con esto, muchas de las cosas que hoy hacemos mediante CodeDom o Expression trees, las podríamos hacer simplemente concatenando strings (hay maneras mejores).

Por ejemplo, imaginemos un framework para crear clases Mock al que llamaremos RinhaMock. Aplicaremos este framework en el siguiente test unitario:

   1: [TestClass]

   2: public class Tests

   3: {

   4:     public void It_should_send_messages_with_values()

   5:     {

   6:         var sentMessage = string.Empty;

7:

   8:         dynamic sender = RinhaMock.Stub<IMessageSender>();

   9:         sender.When_Send_String = new Action<string>(s => sentMessage = s);

10:

  11:         var transacionManager = new TransactionManager(sender);

  12:         transacionManager.Deposit(amount: 50m, accountNo: "0087623481743", concept: "Pago cuota");

13:

  14:         Assert.AreEqual("50;0087623481743;Pago cuota", sentMessage);

  15:     }

  16: }

La idea es crear dinámicamente un tipo que implemente la interface IMessageSender y cuyo comportamiento pueda ser especificado fácilmente. Para que el ejemplo sea bien sencillo, vamos a tener una interface IMessageSender con solo un método y una clase TransactionManager igualmente simple:

   1: public interface IMessageSender

   2: {

   3:     void Send(string message);

   4: }

5:

   6: public class TransactionManager

   7: {

   8:     private IMessageSender _messageSender;

9:

  10:     public TransactionManager(IMessageSender messageSender)

  11:     {

  12:         this._messageSender = messageSender;

  13:     }

14:

  15:     internal void Deposit(decimal amount, string accountNo, string concept)

  16:     {

  17:         // Do the deposit here

  18:         var message = string.Format("{0};{1};{2}", amount, accountNo,concept);

  19:         _messageSender.Send(message);

  20:     }

  21: }

Ahora, la clase stub podría ser escrita por nuestras propias manos, como abajo:

   1: public class Stub__IMessageSender : CSharp5.IMessageSender

   2: {

   3:     public Action<System.String> When_Send_String { get; set; }

   4:     public void Send ( System.String message )

   5:     {

   6:         When_Send_String(message);

   7:     }

   8: }

O bien se podría creada a partir de la metadata de la interface IMessageSender y compilada en tiempo de ejecución. Esta última opción, que hoy tenemos con CodeDom, podría ser mucho más rápida y sencilla si el compilador de C# estuviera disponible como un assembly.

El código necesario para crear el código de la clase stub es el siguiente:

   1: public class RinhaMock

   2: {

   3:     public static T Stub<T>() where T : class

   4:     {

   5:         var typeOfT = typeof(T);

   6:         string stubName = "Stub__" + typeOfT.Name;

   7:         var sb = new StringBuilder();

8:

   9:         var methods = typeOfT

  10:             .GetMethods(BindingFlags.Instance | BindingFlags.Public | BindingFlags.InvokeMethod)

  11:             .Where(m => (m.IsVirtual || m.IsAbstract) && !m.IsSpecialName && !m.IsFinal);

  12:         methods.ForEach(m => sb.AppendLine(GetConfigPropertyCode(m)));

  13:         methods.ForEach(m => sb.AppendLine(GetMethodCode(m)));

14:

  15:         var scripRunner = new ScriptRunner(typeOfT);

  16:         var results = new Dictionary<string, object>();

  17:         scripRunner.AddObject<Dictionary<string, object>>("results", results);

  18:         scripRunner.AddUsing("CSharp5");

  19:         scripRunner.AddTypeCode(string.Format("public class {0} : {1} {{ {2} }}", stubName, typeOfT.FullName, sb.ToString()));

  20:         scripRunner.AddCode("results[\"stub\"] = new " + stubName + "();");

  21:         scripRunner.Run();

22:

  23:         return (T)results["stub"];

  24:     }

25:

  26:     private static string GetMethodCode(MethodInfo method)

  27:     {

  28:         var isProcedure = method.ReturnType == typeof(void);

  29:         var parameters = method.GetParameters();

30:

  31:         return string.Format("public {6} {0} {1} ( {2} ) {{ {3} When_{1}{5}({4}); }}",

  32:             isProcedure ? "void" : method.ReturnType.FullName,

  33:             method.Name,

  34:             parameters.Select(p => string.Concat(p.ParameterType.FullName, " ", p.Name)).ToStringList(),

  35:             isProcedure ? string.Empty : "return",

  36:             parameters.Select(p => p.Name).ToStringList(),

  37:             parameters.Any()

  38:                 ? "_" + parameters.Select(p => p.ParameterType.Name.Replace("[]", "Array")).ToStringList("_")

  39:                 : string.Empty,

  40:             method.DeclaringType.IsInterface ? "" : "override"

  41:             );

  42:     }

43:

  44:     private static string GetConfigPropertyCode(MethodInfo method)

  45:     {

  46:         var isProcedure = method.ReturnType == typeof(void);

  47:         var parameters = method.GetParameters();

48:

  49:         var methodReturnedType = isProcedure ? "void" : method.ReturnType.FullName;

  50:         var parametersType = parameters.Select(p => p.ParameterType);

  51:         var returnedSign = isProcedure ? "Action<{0}>" :

  52:             string.Format("Func<{0}{1}>", "{0}", (parametersType.Any() ? "," : "") + methodReturnedType);

  53:         var parametersForSign = parametersType.Select(t => t.Name.Replace("[]", "Array")).ToStringList("_");

54:

  55:         return string.Format("public {0} When_{1}{2} {{ get; set; }}",

  56:             isProcedure && !parameters.Any()

  57:                 ? "Action"

  58:                 : string.Format(returnedSign, parametersType.Select(t => t.FullName).ToStringList()),

  59:             method.Name,

  60:             parametersType.Any() ? "_" + parametersForSign : string.Empty);

  61:     }

  62: }

63:

  64: static class StringListExtensions

  65: {

  66:     public static string ToStringList(this IEnumerable<string> enumerable, string separator = ", ")

  67:     {

  68:         if (!enumerable.Any())

  69:             return string.Empty;

70:

  71:         return enumerable.Aggregate((s1, s2) => string.Concat(s1, separator, s2));

  72:     }

  73: }

74:

  75: static class IEnumerableExtensions

  76: {

  77:     public static void ForEach<T>(this IEnumerable<T> enumerable, Action<T> action)

  78:     {

  79:         foreach (var t in enumerable) action(t);

  80:     }

  81: }

Como se puede ver, esta podría ser una alternativa viable a todos esos frameworks para la creación de clases proxies como Castle.DynamicProxy (usado por RhinoMocks).

Cómo afectan los Mock frameworks nuestras pruebas unitarias

Lucas Ontivero — Sat, 21 Aug 2010 20:24:41 GMT

Una de las características más importante que debe seguir cualquier código y que es particularmente importante en las pruebas de cualquier tipo es la claridad. Una prueba debe entenderse a la primera sin demasiado esfuerzo, por eso es que debe ser breve, clara y desprovista en el mayor grado posible de elementos ‘ruidosos’. Uno de esos factores ruidosos son los frameworks de aislamiento, los mal llamados Mocking Frameworks. Es por esto que limitar su uso a aquellas ocasiones verdaderamente justificables...(read more)

Como refactorizar métodos estáticos

Lucas Ontivero — Sat, 14 Aug 2010 03:43:29 GMT

Imagina que encontramos un clase estática con varios métodos estáticos los cuales tienen una cantidad aberrante de parámetros. Queremos eliminarla pero nos damos con que está siendo usada en muchísimas partes ¿que hacemos? ¿Como lo harias vos?. Para hablar más concretamente veamos uno de esos métodos: public static void CreateActivityLog( string containerSourceId, string containerId, string action, string sourceId, string instanceId, string docNo, string notes, IFrameworkSecurityContext credentials...(read more)

Fluent Interfaces y TDD

Lucas Ontivero — Fri, 13 Aug 2010 00:04:04 GMT

Desarrollar con TDD al principio no es nada fácil pero luego se vuelve “la manera” de desarrollar. Ahora, no siempre hago TDD, si quiero probar algo tan solo tiro las lineas y listo pero, por otro lado, si quiero hacer algo bien por más que tenga algo de código hecho lo tiro y lo comienzo de nuevo con TDD (nunca he perdido mucho. Por el contrario, lo hago porque veo una diferencia). El asunto es que diseñé una interface fluida para encapsular todos los detalles indeseables de la manipulación de documentos...(read more)