DEV Community: Carlos Vigueras

Cuándo usar Records en .Net

Carlos Vigueras — Sat, 05 Sep 2026 07:47:44 +0000

Como todo en la vida, usar Records en .Net puede ser beneficioso, aunque también, si no se usan adecuadamente, podrían ser contraproducentes.

En esta entrada, os voy a comentar cuándo podría ser beneficioso utilizar Records, y en otra posterior, cuándo no aconsejo usarlos, y si, digo, aconsejo, porque no hay nada que se ajuste 100% a una normativa exacta de uso.

En programación se trata de utilizar un poco la lógica y no usar ciertas prácticas o tecnologías por el mero hecho de haberlas aprendido recientemente o simplemente porque nos gustan; lo importante es saber determinar qué utilizar y en qué momento para adaptar nuestro software a sus necesidades, sin crear una sobreingeniería, introducir código innecesario (YAGNI) o no hacer escalable nuestro software.

Y digo esto anterior, porque al menos en mi caso, cuando empecé a programar aprendía algo y ya quería usarlo en todos los lados, sin pararme a analizar si «eso» que iba a usar era lo apropiado para el momento o no.

Sin más preámbulos, estas son las propiedades fundamentales de los Records y los motivos de su uso:

Inmutabilidad por defecto: Aunque creo que esto ya lo he comentado, los Records nos ofrecen inmutabilidad por defecto, es decir, cuando creamos un Record ya no podremos cambiar sus valores en su instancia por separado, al menos no en esa misma. Si lo que queremos es cambiarle los valores a un Record, tendremos que eliminar dicha instancia y crear una nueva con los valores que queramos.
Igualdad de valores: Cuando trabajamos con clases, si queremos comparar dos instancias de las mismas clases, compararemos las ubicaciones de referencia en la memoria y no el contenido de los objetos en sí. Sin embargo, con los Records se compara tan solo el valor de los mismos, y esto nos ofrece muchas ventajas; nos ahorramos código, por ejemplo.
Los Records son concisos: Los registros ofrecen una forma concisa de definir tipos de datos que no se pueden modificar. Con poco código, es posible declarar propiedades, constructores y otros elementos comunes, lo que disminuye la cantidad de código redundante.
Deconstrucción: Los registros permiten la deconstrucción, facilitando la extracción de valores de propiedades individuales. Esta característica es especialmente útil al trabajar con tuplas o cuando es necesario descomponer un registro en sus elementos.
Método ToString() incorporado: Los registros crean automáticamente un método ToString() significativo que muestra los valores de las propiedades, lo cual simplifica la depuración y el registro. Podremos comprobar dos valores de esta forma:

       Console.WriteLine(new Person("Juan", "Martinez"));  
       //Output: Person { Name = "Juan", Apellido = "Martinez" }

Expresión With para copiar Records: La expresión with permite generar nuevas instancias de un registro con propiedades actualizadas, facilitando la creación de copias modificadas sin alterar la instancia original.

       var person = new Person("Juan", "Martinez");
       var personModified = original with { Apellido = "Gimenez" };
       Console.WriteLine(personModified);  
       //Output: Person { Name = "Juan", Apellido = "Gimenez" }

Coincidencia de patrones: Los registros se integran perfectamente con la coincidencia de patrones en C#, ofreciendo un mecanismo poderoso para manejar estructuras de datos complejas.

      if (person is Person { Name: "Juan", Apellido: "Martinez" })
      {
           Console.WriteLine("That's the correct person!!");
      }

Mayor legibilidad: Los registros mejoran la claridad del código al destacar la finalidad del tipo. Esto resulta particularmente útil en contextos donde los datos son la principal prioridad. En tan solo una línea podremos declarar un nuevo Record con una sencillez clara, a diferencia de una clase en la que tenemos que escribir mucho más código para conseguir lo mismo.
Declaración e inicialización simplificadas: Los registros permiten declarar e inicializar instancias de manera concisa, disminuyendo la cantidad de líneas necesarias en situaciones comunes.
Generación de código: Los registros crean automáticamente métodos comunes, como las comprobaciones de igualdad y ToString, basados en sus propiedades. Esto disminuye la necesidad de implementarlos manualmente y reduce las posibles fuentes de errores.

Confío en que este repaso te haya servido para entender el valor real de los Records. Así, la próxima vez que te enfrentes a un refactor, sabrás determinar con criterio si una clase es la candidata ideal para dar el salto a un Record.

Tened en cuenta que si tenemos Suites de Tests y vamos a cambiar una clase por un Record, nos vamos a ver obligados a cambiar esos Tests muy posiblemente, ya que la inicialización no nos va a servir, pero también que casi seguro veremos que antes teníamos código innecesario tanto en los Tests como en código productivo.

Por normal general los Tests no hay que modificarlos a las bravas, pero si un cambio de implementación en la creación de un objeto cambia, no pasa nada por cambiar el Given de un Test por ejemplo, aunque esto como ya sabéis podremos tenerlo de antes solventado si usamos el Patrón Object Mother, para ese caso con cambiar la forma de crear el objecto en dicho patrón lo tendríamos solucionado en todos los Tests y evitaríamos a la par el Code Smell Shotgun Surgery.

Espero que os haya gustado la entrada y que podáis decirme en comentarios si conocéis alguna ventaja más.

¡Gracias por leerme!

Records en .Net

Carlos Vigueras — Sat, 05 Sep 2026 07:47:34 +0000

En primer lugar, me gustaría comentar que esta entrada la encuadro dentro de Refactoring, ya que a partir de ella podéis aprovechar para refactorizar algunas de vuestras clases y convertirlas a Records.

Los Records existen desde el lanzamiento de C# 9 en noviembre de 2020, hace ya 4 años de esto, pero a pesar de existir hace ya tanto tiempo, su uso no lo he visto muy extendido, al menos en los proyectos que yo he estado implicado, que en 4 años no es que hayan sido muchos, pero tampoco pocos.

Desde mi punto de vista, son muy prácticos de usar, ya que por naturaleza son objetos inmutables, y eso nos ahorra mucho código y lógica de implementación. hasta el punto en el que si no le añadimos ninguna validación, con una sola línea podemos construir un objeto inmutable sin mas complicaciones.

Algo también muy importante es que la igualdad entre dos Records se realiza en base a sus valores, a diferencia de las clases que se realiza en base a sus referencias.

Esto último es importante, pues nos facilita la vida a la hora de realizar los Tests, pero esto lo veremos en otra entrada.

Los Records son definidos así:

Vamos a ver de forma muy rápida y sencilla las diferencias mas esenciales entre las Clases y los Records:

Diferencias clave entre clases y registros

Mutabilidad:

Clases : Las clases son mutables de forma predeterminada, lo que permite cambiar las propiedades después de la instanciación a nuestro antojo.
Registros : Los registros son inmutables de forma predeterminada, lo que significa que sus propiedades son de solo lectura y se pueden asignar sólo en la inicialización.

Igualdad de Valores:

Clases : En una clase necesitamos en algún caso dado la implementación manual de los métodos Equals y GetHashCode necesarios para comprobar la igualdad basada en valores, y estos métodos en muchas ocasiones los he visto implementados sólo para poder utilizarlos en los Tests, y deberíamos saber que generar código productivo sólo para que nos funciones un Test no es correcto.
Registros : Los registros implementan por naturaleza propia métodos de igualdad basados en valores, lo que simplifica las comparaciones de valores.

Código:

Clases : Escribir clases puede implicar código repetitivo para propiedades, constructores, métodos de igualdad..etc, y además se puede hacer bastante pesado crear una clase inmutable, sobre todo si contiene muchas propiedades.
Registros : Los registros son más concisos y generan automáticamente métodos comunes basados en las propiedades.

Vamos a ver un ejemplo de código de un Record, para quien nadie los haya usado y así os pongo mas en contexto:

   public record Person(string Nombre, string Apeliido,
        string Direccion, int Edad, string Sexo);

Un record simplemente se crea de esta forma, y si le incluimos un Test podremos ver como comparando los dos objetos creados el resultado del Test es verde, ya que como he dicho arriba al ser un Record comprueba por valor y no por referencia.

Pero esto no queda aquí, a los Records podemos añadirle validaciones, no tienen por qué quedarse como una simple DataClass sin mas lógica, veamos un ejemplo con una validación:

public record Person(string Nombre, string Apeliido,
    string Direccion, int Edad, string Sexo)
{
    private string _nombre = EsNombreValido(Nombre);
    public string Nombre
    {
        get => _nombre;
        init => _nombre = EsNombreValido(value);
    }

    private static string EsNombreValido(string nombre)
    {
        if(nombre.Length > 10)
            throw new Exception();
        return nombre;
    }
}

En este ejemplo vemos como estamos validando la propiedad Nombre, del objeto Record Person, y si su longitud es mayor que 10 vamos a lanzar una excepción, y a la par estamos respetando la inmutabilidad del objeto.

De esta forma estamos creando un objeto inmutable por naturaleza y estamos realizando una validación sobre una de sus propiedades, por lo que este sería un buen ejemplo a usar con un Value Object, aunque los Value Object los veremos mas detenidamente en otra entrada.

Pues ya está Carlos, si me dices esto, no vuelvo a usar clases, usaré siempre Records!!

Bueno, no exactamente así, no nos tomemos todo al pìe de la letra, los Records los podemos usar en muchísimos casos, pero sobre todo se recomienda usarlos siempre que queramos tener objetos inmutables, pero por favor no siempre, hay muchos casos en los que es mas ventajoso utilizar una clase.

En la próxima entrada os voy a comentar mas en profundidad cuando es recomendable usar Records y por qué.

Espero que os haya sido de ayuda. ¿Vosotros soléis usar Records?

!Os leo en comentarios!

Patrón Object Mother con AutoFixture

Carlos Vigueras — Sat, 05 Sep 2026 07:47:21 +0000

En esta entrada, la cual va a ser bastante sencilla, os voy a hablar del Patrón Object Mother, combinado con AutoFixture, y si, os lo podéis imaginar, es tan simple como usar dicho Patrón y en él implementar AutoFixture.

De este modo aprovechamos, por un lado, la semántica que le damos a los Tests con el patrón Object Mother, y por el otro la versatilidad que nos ofrece AutoFixture.

Para implementar esta técnica simplemente hemos de usar dentro de las clases del patrón Object Mother la librería de AutoFixture, y dicha combinación nos va a facilitar mucho el desarrollo de nuestros Tests.

Como siempre vamos a ver un ejemplo y así lo veremos todo mas claro.

Voy a utilizar el ejemplo de Object Mother, modificándolo, y añadiéndole AutoFixture a los ejemplos, de este modo vamos a ver lo sencillo que es:

User.cs

    public class User
    {
        public string Name { get; set; }
        public int Age { get; set; }

        public User(string name, int age)
        {
            Name = name;
            Age = age;
        }
        public static User Create(string name, int age)
        {
            return new User(name, age);
        }
    }

Home.cs

    public class Home
    {
        public string Access(User user)
        {
            switch (user.Age)
            {
                case < 18:
                    return "Aplicación web solo para personas mayores de edad";
                case < 30:
                    return "Consigue un descuento de 20€ en tu primer pedido";
                case < 65:
                    return "Consigue un descuento de 25€ en tu primer pedido";
                case > 65:
                    return "Consigue un descuento de 30€ en tu primer pedido";
                default:
                    return string.Empty;
            }
        }
    }

UserShould.cs

public partial class UserShould
{
    private Home home;
    [SetUp]
    public void Setup()
    {
        home = new Home();
    }

    [Test]
    public void get_message_under_eighteen_years()
    {
        //Given
        var givenUserUnderEighteen = UserMother.UserUnderEighteen();

        //When
        var message = home.Access(givenUserUnderEighteen);

        //Then
        Assert.IsTrue(string.Equals(message, "Aplicación web solo para personas mayores de edad",
            StringComparison.OrdinalIgnoreCase));
    }

    [Test]
    public void get_message_over_eighteen_under_thirty_years()
    {
        //Given
        var givenUserOverEighteenUnderThirty = UserMother.UserOverEighteenUnderThirty();

        //When
        var message = home.Access(givenUserOverEighteenUnderThirty);

        //Then
        Assert.IsTrue(string.Equals(message, "Consigue un descuento de 20€ en tu primer pedido",
            StringComparison.OrdinalIgnoreCase));
    }

    [Test]
    public void get_message_over_thirty_under_sixty_five_years()
    {
        //Given
        var givenUserOverThirtyUnderSixtyFive = UserMother.UserOverThirtyUnderSixtyFive();

        //When
        var message = home.Access(givenUserOverThirtyUnderSixtyFive);

        //Then
        Assert.IsTrue(string.Equals(message, "Consigue un descuento de 25€ en tu primer pedido",
            StringComparison.OrdinalIgnoreCase));
    }

    [Test]
    public void get_message_over_sixty_five_years()
    {
        //Given
        var givenUserOverSixtyFive = UserMother.UserOverSixtyFive();

        //When
        var message = home.Access(givenUserOverSixtyFive);

        //Then
        Assert.IsTrue(string.Equals(message, "Consigue un descuento de 30€ en tu primer pedido",
            StringComparison.OrdinalIgnoreCase));
    }
}

UserMother.cs

    public class UserMother
    {
        private static Fixture _fixture = new Fixture();

        public static User UserUnderEighteen()
        {
            return _fixture.Build<User>()
                            .With(u => u.Age, 16)
                            .Create();
        }

        public static User UserOverEighteenUnderThirty()
        {
            return _fixture.Build<User>()
                            .With(u => u.Age, 29)
                            .Create();
        }

        public static User UserOverThirtyUnderSixtyFive()
        {
            return _fixture.Build<User>()
                            .With(u => u.Age, 46)
                            .Create();
        }

        public static User UserOverSixtyFive()
        {
            return _fixture.Build<User>()
                            .With(u => u.Age, 67)
                            .Create();
        }
    }

Claramente, se puede ver como hemos combinado el Patrón Object Mother y Autofixture, y de este modo agrupamos la creación de los objetos que necesitamos, y como decíamos arriba, no perdemos la semántica de los Tests, y a la par podemos usar cómodamente AutoFixture.

Con este método abstraemos totalmente de los Tests de cómo estén creados los datos, y una vez se puede ver de forma sencilla cual es el dato.

De este modo cualquier modificación de los datos se hará de forma centralizada en la clase UserMother.cs, del mismo modo que se hacía antes, y como dejaremos que nuestros Tests se abstraigan totalmente de la lógica de creación de datos, reduciendo la complejidad en los mismos, y como siempre he dicho, quedan mas simples y se entienden mejor.

Me gustaría que pusieseis en comentarios cualquier otra técnica o patrón que hayáis usado para la creación de datos en los Tests, o cualquier técnica que queráis compartir.

¿Os ha gustado esta combinación?

Saludos, y como siempre, gracias por leerme!!

Autofixture con entidades inmutables

Carlos Vigueras — Sat, 05 Sep 2026 07:47:10 +0000

Estoy seguro que recordáis que en la última entrada estuvimos viendo como usar AutoFixture para construir datos de prueba en nuestros Tests, y seguro que recordáis que se cerraba la entrada comentando que si usábamos AutoFixture con entidades inmutables su comportamiento sería o no el mismo, que si lo usamos con entidades no inmutables, ya que el ejemplo que se veía en la anterior entrada es este último.

Bueno, pues en esta entrada vamos a ver su comportamiento, y como solventarlo.

Sigamos con los Tests de la entidad User, pero esta vez la entidad User va a ser inmutable.

    public class User
    {
        public string Name { get; }
        public string LastName { get; }
        public string City { get; }
        public string PhoneNumber { get; }
        public string Gender { get; }
        public string Email { get; }
        public string MobileNumber { get; }
        public int Age { get; }

        private User(string name,
                    string lastName,
                    string city,
                    string phoneNumber,
                    string gender,
                    string email,
                    string mobileNumber,
                    int age)
        {
            Name = name;
            LastName = lastName;
            City = city;
            PhoneNumber = phoneNumber;
            Gender = gender;
            Email = email;
            MobileNumber = mobileNumber;
            Age = age;
        }

        public static User Create(string name,
                    string lastName,
                    string city,
                    string phoneNumber,
                    string gender,
                    string email,
                    string mobileNumber,
                    int age)
        {
            return new User(name, lastName, city, 
                phoneNumber, gender, email, mobileNumber, age);
        }
    }

Ya hemos hecho a la entidad User inmutable, podéis ver como una vez que creemos un objeto de User ya no podremos modificar sus valores, por lo que nadie podrá alterar su valor una vez creada una instancia del objeto.

Bien, pues vamos a proceder a usar esta entidad en nuestros Tests, de la misma forma que lo hacíamos en la anterior entrada pero de momento sin customizar la edad, y vamos a ver el resultado:

public class UserShould
{
    private Fixture fixture;

    [SetUp]
    public void Setup()
    {
        fixture = new Fixture();
    }

    [Test]
    public void get_user_successfully_when_create_with_autofixture()
    {
        var user = fixture.Create<User>();

        Assert.IsNotNull(user);
    }
}

Aunque se que este Test no tiene mucho sentido, es solo de ejemplo para que se pueda ver el comportamiento de AutoFixture en este escenario.

El resultado de este Test es correcto, o sea, nos da verde, a pesar de ser una entidad inmutable ha creado la instancia del objeto perfectamente, sin ningún problema, y aquí dejo mis evidencias:

Hasta aquí todo está correcto ¿no?

¿Y si queremos customizar la edad ya que es el propósito del Test?

Bien, pues vamos a probarlo y a ver el resultado:

[Test]
public void get_message_under_eighteen_years()
{
    var givenUserUnderEighteen = fixture.Build<User>()
                                 .With(u => u.Age, 16)
                                 .Create();

    var message = home.Access(givenUserUnderEighteen);

    Assert.IsTrue(string.Equals(message, 
         "Aplicación web solo para personas mayores de edad", 
          StringComparison.OrdinalIgnoreCase));
}

Efectivamente, tal y como os estabais imaginando no os va a dejar crear el objeto con la propiedad Age customizada, ya que esta es de solo lectura.

Por lo que no solo es que tengamos el Test en rojo, si no que estamos recibiendo un excepción no controlada en nuestros Tests, y esto no es correcto.

¿Y nos vamos a conformar con esto ? Yo no!!

Yo, que me acabo de enterar que las entidades hay que crearlas inmutables, he refactorizado todo mi código y he creado las entidades inmutables y ahora los Test me dan rojo, me saltan excepciones por todos los lados, con lo bonito que había dejado yo todo mi código refactorizado y ahora esto.

Buscando y buscando, buceando entre hilos e hilos de otros programadores buscando la misma solución al mismo problema, de repente.. !Eureka¡

!AutoFixture se puede customizar¡

Si, AutoFixture se puede customizar, y no es que lo diga yo, si no que lo comentan en StackOverflow, y si lo ahí lo dicen tiene que funcionar sí o sí, bueno o no, no sabemos, pero podemos probar.

La solución que se aporta de primeras es la de «mientras las propiedades sean readonly*, se puede definir un SpecimenBuilder personalizado para el tipo, y que se puede generalizar la customización para que funcione con cualquier propiedad».

La teoría es muy bonita, ¿pero esto funcionará?

Pues vamos a probarlo y salgamos de dudas. Customizamos de forma generalizada para trabajar con cualquier propiedad usando un Tipo T como genérico.

public class OverridePropertyBuilder<T, TProp> : ISpecimenBuilder
{
    private readonly PropertyInfo _propertyInfo;
    private readonly TProp _value;
    public OverridePropertyBuilder(Expression<Func<T, TProp>> expr, TProp value)
    {
        _propertyInfo = (expr.Body as MemberExpression)?.Member as PropertyInfo ??
                        throw new InvalidOperationException("invalid property expression");
        _value = value;
    }
    public object Create(object request, ISpecimenContext context)
    {
        var pi = request as ParameterInfo;
        if (pi == null)
            return new NoSpecimen();
        var camelCase = Regex.Replace(_propertyInfo.Name, @"(\w)(.*)",
            m => m.Groups[1].Value.ToLower() + m.Groups[2]);
        if (pi.ParameterType != typeof(TProp) || pi.Name != camelCase)
            return new NoSpecimen();
        return _value;
    }
}

El código de arriba define una clase genérica OverridePropertyBuilder<T, TProp> que implementa la interfaz ISpecimenBuilder. Sobreescribe las propiedades de un objeto utilizado con AutoFixture.

Y posteriormente necesitamos métodos de extensión personalizados para facilitar su uso:

public class FixtureCustomization<T>
{
    public Fixture Fixture { get; }

    public FixtureCustomization(Fixture fixture)
    {
        Fixture = fixture;
    }

    public FixtureCustomization<T> With<TProp>(Expression<Func<T, TProp>> expr, TProp value)
    {
        Fixture.Customizations.Add(new OverridePropertyBuilder<T, TProp>(expr, value));
        return this;
    }

    public T Create() => Fixture.Create<T>();
}

public static class CompositionExt
{
    public static FixtureCustomization<T> For<T>(this Fixture fixture)
        => new FixtureCustomization<T>(fixture);
}

Y en la segunda se define una clase FixtureCustomization para ayudar a personalizar los fixture y una clase de extensión estática CompositionExt para proporcionar una forma conveniente de crear instancias FixtureCustomization.

Y de esta forma ya podremos crear objetos inmutables personalizados usando AutoFixture:

 var givenUserUnderEighteen =
   new Fixture()
     .For<User>()
     .With(x => x.Age, 16)
     .Create();

Ahora ya podemos ver que con esta customización nos ha dejado crear el objeto sin ningún problema:

Pero la mejor forma de que entendáis este código es que lo probéis y lo depuréis. Os dejo mi ejemplo completo en GitHub para que le echéis un ojo.

¿ Que os ha parecido esta entrada? ¿ Cuál de todas las técnicas que hemos visto preferís ?

AutoFixture para creación de valores aleatorios e instancias.

Carlos Vigueras — Sat, 05 Sep 2026 07:47:01 +0000

En primer lugar de todos, quisiera matizar, que AutoFixture no es un Patrón de diseño, es tan solo una librería de código abierto, la cual podemos hacer uso cualquiera que la necesitemos descargándola de los Paquetes Nugets. En su proyecto de GitHub es definida de la siguiente forma:

Cuando tenemos que realizar Tests en los que están implicados objetos complejos, podemos utilizar AutoFixture, y de este modo nos olvidamos de ir asignando campo a campo un objeto, imaginad un objeto muy largo, o muy complejo, no sólo nos cuesta la creación manual del mismo, si no que como hemos visto ya, perdemos un la semántica de los Tests. Además la creación de este tipo de Tests se nos convertirá en una tarea compleja, escribiendo código que no es relevante para el Test.

Si lo que queremos es automatizar la creación de nuestros objetos o entidades con valores aleatorios estaremos usando la librería correcta, ya que lo conseguiremos de una forma rápida y limpia.

¿Pero con AutoFixture sólo puedo crear objetos con propiedades aleatorias?

Realmente, podremos crear objetos de forma automatizada con campos aleatorios, y si lo deseamos en algún caso también personalizados, pero eso lo veremos en breve.

Como siempre vamos a ver un ejemplo, y lo veremos con el proyecto del User que veíamos en las entradas de Object Mother y Patrón Builder:

User.cs

    public class User
    {
        public string Name { get; set; }
        public string LastName { get; set; }
        public string City { get; set; }
        public string PhoneNumber { get; set; }
        public string Gender { get; set; }
        public string Email { get; set; }
        public string MobileNumber { get; set; }
        public int Age { get; set; }


        public User(string name,
                    string lastName,
                    string city,
                    string phoneNumber,
                    string gender,
                    string email,
                    string mobileNumber,
                    int age)
        {
            Name = name;
            LastName = lastName;
            City = city;
            PhoneNumber = phoneNumber;
            Gender = gender;
            Email = email;
            MobileNumber = mobileNumber;
            Age = age;
        }
    }

Home.cs

    public class Home
    {
        public string Access(User user)
        {
            switch (user.Age)
            {
                case < 18:
                    return "Aplicación web solo para personas mayores de edad";
                case < 30:
                    return "Consigue un descuento de 20€ en tu primer pedido";
                case < 65:
                    return "Consigue un descuento de 25€ en tu primer pedido";
                case > 65:
                    return "Consigue un descuento de 30€ en tu primer pedido";
                default:
                    return string.Empty;
            }
        }
    }

UserShould.cs

public class UserShould
{
    private Home home;
    [SetUp]
    public void Setup()
    {
        home = new Home();
    }

    [Test]
    public void get_message_under_eighteen_years()
    {
        //Given
        var givenUserUnderEighteen = new User("Pepito",
                                              "Grillo",
                                              "Murcia",
                                              "000000000",
                                              "Hombre",
                                              "pepitogrillo@anyemail.com",
                                              "000000000",
                                              16);

        //When
        var message = home.Access(givenUserUnderEighteen);

        //Then
        Assert.IsTrue(string.Equals(message, "Aplicación web solo para personas mayores de edad",
            StringComparison.OrdinalIgnoreCase));
    }

    [Test]
    public void get_message_over_eighteen_under_thirty_years()
    {
        //Given
        var givenUserOverEighteenUnderThirty = new User("Pepito",
                                              "Grillo",
                                              "Murcia",
                                              "000000000",
                                              "Hombre",
                                              "pepitogrillo@anyemail.com",
                                              "000000000",
                                              29);

        //When
        var message = home.Access(givenUserOverEighteenUnderThirty);

        //Then
        Assert.IsTrue(string.Equals(message, "Consigue un descuento de 20€ en tu primer pedido",
            StringComparison.OrdinalIgnoreCase));
    }

    [Test]
    public void get_message_over_thirty_under_sixty_five_years()
    {
        //Given
        var givenUserOverThirtyUnderSixtyFive = new User("Pepito",
                                              "Grillo",
                                              "Murcia",
                                              "000000000",
                                              "Hombre",
                                              "pepitogrillo@anyemail.com",
                                              "000000000",
                                              46);

        //When
        var message = home.Access(givenUserOverThirtyUnderSixtyFive);

        //Then
        Assert.IsTrue(string.Equals(message, "Consigue un descuento de 25€ en tu primer pedido",
            StringComparison.OrdinalIgnoreCase));
    }

    [Test]
    public void get_message_over_sixty_five_years()
    {
        //Given
        var givenUserOverSixtyFive = new User("Pepito",
                                              "Grillo",
                                              "Murcia",
                                              "000000000",
                                              "Hombre",
                                              "pepitogrillo@anyemail.com",
                                              "000000000",
                                              67);

        //When
        var message = home.Access(givenUserOverSixtyFive);

        //Then
        Assert.IsTrue(string.Equals(message, "Consigue un descuento de 30€ en tu primer pedido",
            StringComparison.OrdinalIgnoreCase));
    }
}

Ahora la clase User.cs contiene ocho propiedades, que si bien no son muchas, si son más de las que antes teníamos, y poco a poco se va haciendo un poco mas complicado rellenar el objeto, aparte de que tenemos que ir repitiendo por cada uno de los Tests la creación del objeto.

Si, muchos me podéis decir que os crearíais un método que generase un objeto User.cs con el parámetro Age pasado por valor, ya que es el único cambiante, pero esto, una vez mas rompería la semántica de los Tests, y aparte la creación del objeto, aunque sea sólo una vez no nos la quita nadie.

Como ya os habréis dado cuenta, aquí la única propiedad que difiere de las demás es Edad, ya que el propósito de los Tests es chequear la edad que tiene el User y en base a eso, envía un mensaje u otro, por lo que podríamos crear un objeto User.cs con valores aleatorios, excepto con la edad que podría ser cambiante, ¿verdad?

Pues vamos a ello, lo primero de todo, hemos de instalar AutoFixture en nuestro proyecto de Tests:

Para este caso instalamos la Versión 4.18.1 que es la última que hay actualmente. Una vez instalado AutoFixture, vamos a proceder a usarlo en nuestros Tests. Vamos a refactorizarlos:

UserShould.cs con AutoFixture

public class UserShould
{
    private Home home;
    private Fixture fixture;

    [SetUp]
    public void Setup()
    {
        home = new Home();
        fixture = new Fixture();
    }

    [Test]
    public void get_message_under_eighteen_years()
    {
        //Given
        var givenUserUnderEighteen = fixture.Build<User>()
                                            .With(u => u.Age, 16)
                                            .Create();

        //When
        var message = home.Access(givenUserUnderEighteen);

        //Then
        Assert.IsTrue(string.Equals(message, "Aplicación web solo para personas mayores de edad",
            StringComparison.OrdinalIgnoreCase));
    }

    [Test]
    public void get_message_over_eighteen_under_thirty_years()
    {
        //Given
        var givenUserOverEighteenUnderThirty = fixture.Build<User>()
                                            .With(u => u.Age, 29)
                                            .Create();

        //When
        var message = home.Access(givenUserOverEighteenUnderThirty);

        //Then
        Assert.IsTrue(string.Equals(message, "Consigue un descuento de 20€ en tu primer pedido",
            StringComparison.OrdinalIgnoreCase));
    }

    [Test]
    public void get_message_over_thirty_under_sixty_five_years()
    {
        //Given
        var givenUserOverThirtyUnderSixtyFive = fixture.Build<User>()
                                            .With(u => u.Age, 46)
                                            .Create();

        //When
        var message = home.Access(givenUserOverThirtyUnderSixtyFive);

        //Then
        Assert.IsTrue(string.Equals(message, "Consigue un descuento de 25€ en tu primer pedido",
            StringComparison.OrdinalIgnoreCase));
    }

    [Test]
    public void get_message_over_sixty_five_years()
    {
        //Given
        var givenUserOverSixtyFive = fixture.Build<User>()
                                            .With(u => u.Age, 67)
                                            .Create();

        //When
        var message = home.Access(givenUserOverSixtyFive);

        //Then
        Assert.IsTrue(string.Equals(message, "Consigue un descuento de 30€ en tu primer pedido",
            StringComparison.OrdinalIgnoreCase));
    }
}

Ahora en los Tests de UserShould.cs usamos AutoFixture, y le hemos dado mas semántica a nuestros Tests,

¿Por qué?

Muy sencillo, ahora podemos ver como pedimos un usuario con una edad concreta en cada uno de los Tests, y nos queda claro cual es la regla de negocio que se ha de cumplir para que el Tests sea correcto, de la forma anterior, veíamos un montón de propiedades, y aunque en el ejemplo era bastante obvio a que se hacía referencia, no en todos los casos va a ser así.

Vamos a ver como nos ha creado AutoFixture el objeto:

Podemos ver, cómo a las propiedades de User.cs les ha dado un valor aleatorio, excepto a la edad, que es justo lo que le hemos indicado.

¿Qué mas da el nombre o el apellido del usuario o las demás variables?

Para estos Tests solo nos importa la edad, lo demás queda asignado de forma automática. Y como hemos dicho los Tests ahora tienen mas semántica y se entiende mejor el propósito y la regla de negocio que ha de cumplirse.

Pero como todo no va a ser fantástico y maravilloso, os pregunto:

¿Qué sucede si usamos AutoFixture con objetos inmutables? ¿Creéis que funcionará por defecto?

!Os leo en los comentarios!

Patrón Builder

Carlos Vigueras — Sat, 05 Sep 2026 07:46:50 +0000

Hace unos días escribí una entrada sobre el Patrón Object Mother de Martín Fowler, en la que hacía referencia al Patrón Builder, del cual, la verdad, es que no soy muy partidario de utilizarlo en Test, pero aún así y a petición de un lector que puso un comentario solicitando un ejemplo voy a hablar de él.

El Patrón Builder es un patrón de diseño creacional, el cual nos permite crear objetos complejos, y no necesariamente se usa para crear estructuras de datos en Test, si no que se usa también en muchas ocasiones en código productivo.

No obstante hay muchos programadores que lo usan para crear objetos complejos y usarlos en Suite de Tests, sobre este tema os encontraréis muchos detractores de usar este patrón en Test, y otros tantos a favor, por lo que esto va en cuestión de gustos.

En esta entrada solo me voy a dedicar a explicar como usarlo como una alternativa a los Object Mother, bueno pues como se suele decir… vamos al grano!!

Cuando estamos testeando en alguna aplicación alguna funcionalidad, siempre hemos de procurar discernir la parte de los datos de la parte de Test, y de este modo podremos tener unos test mas claros y entendibles, ¿cuantas veces habré dicho esas palabras?, lo que es igual a decir que mejoraremos la semántica de los Tests, ya que estaremos separando la parte de creación de datos con la parte del testeo en sí.

Sin irnos por los Cerros de Úbeda, vamos a entrar en materia, y para ello pues vamos a usar el mismo ejemplo que tenemos de Object Mother, modificándolo y lo dejaré en mi GitHub para que también le echéis un vistazo.

Para que el ejemplo sea mas entendible no voy a usar la creación de un objeto complejo, pero entended que el Patrón Builder es para la creación de objetos complejos.

User.cs

    public class User
    {
        public string Name { get; set; }
        public int Age { get; set; }

        public User(string name, int age)
        {
            Name = name;
            Age = age;
        }
        public static User Create(string name, int age)
        {
            return new User(name, age);
        }
    }

Home.cs

    public class Home
    {
        public string Access(User user)
        {
            switch (user.Age)
            {
                case < 18:
                    return "Aplicación web solo para personas mayores de edad";
                case < 30:
                    return "Consigue un descuento de 20€ en tu primer pedido";
                case < 65:
                    return "Consigue un descuento de 25€ en tu primer pedido";
                case > 65:
                    return "Consigue un descuento de 30€ en tu primer pedido";
                default:
                    return string.Empty;
            }
        }
    }

UserShould.cs

 public class UserShould
 {
     private Home home;
     [SetUp]
     public void Setup()
     {
         home = new Home();
     }

     [Test]
     public void get_message_under_eighteen_years()
     {
         //Given
         var givenUserUnderEighteen = new UserBuilder().WithName("Pepito")
             .WithAge(16)
             .Build();

         //When
         var message = home.Access(givenUserUnderEighteen);

         //Then
         Assert.IsTrue(string.Equals(message, "Aplicación web solo para personas mayores de edad",
             StringComparison.OrdinalIgnoreCase));
     }

     [Test]
     public void get_message_over_eighteen_under_thirty_years()
     {
         //Given
         var givenUserOverEighteenUnderThirty = new UserBuilder().WithName("Pepito")
             .WithAge(29)
             .Build();

         //When
         var message = home.Access(givenUserOverEighteenUnderThirty);

         //Then
         Assert.IsTrue(string.Equals(message, "Consigue un descuento de 20€ en tu primer pedido",
             StringComparison.OrdinalIgnoreCase));
     }

     [Test]
     public void get_message_over_thirty_under_sixty_five_years()
     {
         //Given
         var givenUserOverThirtyUnderSixtyFive = new UserBuilder().WithName("Pepito")
             .WithAge(46)
             .Build();

         //When
         var message = home.Access(givenUserOverThirtyUnderSixtyFive);

         //Then
         Assert.IsTrue(string.Equals(message, "Consigue un descuento de 25€ en tu primer pedido",
             StringComparison.OrdinalIgnoreCase));
     }

     [Test]
     public void get_message_over_sixty_five_years()
     {
         //Given
         var givenUserOverSixtyFive = new UserBuilder().WithName("Pepito")
             .WithAge(67)
             .Build();

         //When
         var message = home.Access(givenUserOverSixtyFive);

         //Then
         Assert.IsTrue(string.Equals(message, "Consigue un descuento de 30€ en tu primer pedido",
             StringComparison.OrdinalIgnoreCase));
     }
 }

UserBuilder.cs

public class UserBuilder
{
    private string Name;
    private int Age;

    public UserBuilder WithName(String name)
    {
        this.Name = name;
        return this;
    }

    public UserBuilder WithAge(int age)
    {
        this.Age = age;
        return this;
    }

    public User Build()
    {
        return new User (Name, Age);
    }
}

En este caso con el Patrón Builder nos estamos apoyando en una clase externa como con el Patrón Object Mother para conseguir los datos tal y como los queremos para nuestros tests, pero en mi opinión, no queda tan claro que es exactamente lo que queremos conseguir con esos tests, es decir, el nombre de las funciones no es tan declarativo como en Object Mother, y esto, bajo mi punto de vista, no nos ofrece una buena semántica a nuestros Tests.

Sin lugar a dudas, es una forma diferente de crear datos para Tests, y para gustos, como dicen, los colores.

A día de hoy para separar creación de datos y test he usado estas cuatro técnicas:

Patrón Object Mother
Patrón Builder.
AutoFixture, del que hablaré en una futura entrada.
AutoFixture con entidades inmutables
Patrón Object Mother combinado con AutoFixture, del que también hablaré.

Estoy seguro que muchos de vosotros conocéis alguna mas, por lo que me gustaría me las expongais en comentarios.

¿Cuales habéis usado vosotros?

¿Que opináis del Patrón Builder en los Tests?

Data Clumps

Carlos Vigueras — Sat, 05 Sep 2026 07:46:39 +0000

Hablando en términos de programación orientada a objetos , «Data Clumps» es el nombre que recibe un grupo de variables que se pasan juntas en grupo, a lo largo de varias partes del programa.

Un Data Clumps (grupo de datos), es un indicador de un Code Smells, que recibe ese mismo nombre , y esto puede indicar problemas más profundos con el diseño o con la implementación del programa.

Este grupo de variables que componen un grupo de datos, suelen estar relacionados, pero como resultado, a menudo se utilizan juntos en grupo, ya que juntas tienen un significado concreto.

Este conocido Code Smell puede ser un síntoma de que un código esté mal desarrollado, y esto puede acarrear otros problemas a la hora de que nuestro código evolucione en un futuro.

Cuando detectemos este Code Smell en nuestro código hemos de tener en cuenta que debemos pararnos a analizar que podemos estar haciendo mal, y de que forma podemos modificar el código para que quede mejor estructurado.

Bien sabemos que cuanto más limpio y más legible sea nuestro código, más fácil será entenderlo y modificarlo, y más escalable será nuestro software.

Pero como siempre, vamos a ver un ejemplo de código y su posible refactorización, y de esta forma lo vamos a ver todo mas claro.

Supongamos que vamos a programar una aplicación de alquiler de coches, en la cual, vamos a registrar a un usuario, con su nombre, su DNI, su edad, su número de carnet de conducir, y el periodo de tiempo en el que va a alquilar el coche.

    public class Booking
    {
        public Booking(string name, string dni, int age, string drivingLicence, DateTime from, DateTime to)
        {
            Name = name;
            DNI = dni;
            Age = age;
            DrivingLicence = drivingLicence;
            From = from;
            To = to;
        }

        public string Name { get; set; }
        public string DNI { get; set; }
        public int Age { get; set; }
        public string DrivingLicence { get; set; }
        public DateTime From { get; set; }
        public DateTime To { get; set; }
    }

var booking = new Booking("Carlos", "12345678Z", 22, "0987654567", 
    DateTime.Now, DateTime.Now.AddDays(5));

Como se puede ver en el ejemplo de arriba, tenemos dos grupos de datos, que se le pasan al constructor de la clase Booking(), y que perfectamente se podrían disociar en dos clases distintas.

Podríamos decir que tenemos dos grupos, por un lado sería el grupo de datos de usuario, y por el otro el grupo de fechas de la reserva, por lo que podríamos proceder a separar cada uno de ellos.

Comencemos con el Usuario:

    public class Booking
    {
        public User User { get; set; }
        public DateTime From { get; set; }
        public DateTime To { get; set; }

        public Booking(User user, DateTime from, DateTime to)
        {
            User = user;
            From = from;
            To = to;
        }

    }

    public class User
    {
        public string Name { get; set; }
        public string DNI { get; set; }
        public int Age { get; set; }
        public string DrivingLicence { get; set; }

        public User(string name, string dni, int age, string drivingLicence)
        {
            Name = name;
            DNI = dni;
            Age = age;
            DrivingLicence = drivingLicence;
        }
    }

var booking = new Booking(new User("Carlos", "12345678Z", 22, "0987654567"), 
    DateTime.Now, DateTime.Now.AddDays(5));

Aquí lo único que hemos hecho es llevarnos el grupo de variables que pertenece al grupo usuario, y meterlas en una clase llamada User, de este modo, User es responsable de validar sus propiedades en cualquier momento, y además esas variables primitivas las dejamos centralizadas en la clase User.

Hagamos lo mismo con el grupo de variables de fecha de reserva.

    public class Booking
    {
        public User User { get; set; }
        public TimeInterval TimeInterval { get; set; }

        public Booking(User user, TimeInterval timeInterval)
        {
            User = user;
            TimeInterval = timeInterval;
        }
    }

    public class TimeInterval
    {
        public DateTime From { get; set; }
        public DateTime To { get; set; }

        public TimeInterval(DateTime from, DateTime to)
        {
            From = from;
            To = to;
        }
    }

var booking = new Booking(new User("Carlos", "12345678Z", 22, "0987654567"), 
    new TimeInterval(DateTime.Now, DateTime.Now.AddDays(5)));

Para TimeInterval hemos hecho lo mismo, hemos agrupado las propiedades primitivas que contenía Booking, ya que es responsabilidad de TimeInterval validar las fechas, que por ejemplo el valor de la variable From no sea inferior a hoy, o cualquier validación que se os pueda ocurrir. De este modo vemos como aplicamos que cada clase asuma la responsabilidad que tiene que tener, que para este caso, es la de validar su propiedades.

Si nos damos cuenta, también hemos cumplido en la clase TimeInterval() la regla número 9 de Object Calisthenics de Evitar mas de dos atributos de instancia

Os dejo en GitHub el repositorio de código que he usado de ejemplo por si queréis echarle un vistazo.

Espero leeros en comentarios vuestra opinión sobre este Code Smell. Gracias.

Regla de tres

Carlos Vigueras — Sat, 05 Sep 2026 07:46:05 +0000

Hablando en términos de refactorización de código, la regla de tres, es una regla muy útil que siempre aconsejo aplicar cuando estemos realizando nuevos desarrollos o nuevas funcionalidades en una aplicación. Y no es que lo diga yo, si no que Martin Fowler propone aplicar la regla de tres de la siguiente forma:

Cuando hagas algo por primera vez, hazlo.
Cuando hagas algo parecido por segunda vez, no te conformes con tener que repetirlo, pero hazlo de todos modos.
Cuando hagas algo por tercera vez, empieza a refactorizar.

La refactorización en nuestros proyectos es muy importante, ya que cuando refactorizamos un código, no solo vamos a ayudar a los demás que vengan detrás, si no que nos ayudaremos a nosotros mismos a entender mejor el código, y a tener un código mas limpio, legible y entendible.

Y siempre debemos aplicar refactorización de código en todo los casos, bien cuando estemos agregando una característica, cuando estemos corrigiendo un error o cuando estemos haciendo un revisión de código.

Aunque todo esto es muy fácil de entender, vamos a ver un código de ejemplo muy sencillo, y vamos paso a paso, viendo cómo iríamos refactorizando.

Supongamos, que tenemos tres clases, la clase Gato, la clase Pájaro y la clase Serpiente. Comencemos con la clase Gato.

    public class Gato
    {
        public int NumeroPatas { private get; set; }
        public string Especie { private get; set; }

        public int GetNumeroPatas()
        {
            return NumeroPatas;
        }

        public string TipoEspecie()
        {
            return Especie;
        }
    }

Hasta aquí todo bien, tenemos una clase Gato, la cual tiene dos propiedades, NumeroPatas y Especie, y dos métodos GetNumeroPatas() y TipoEspecie(), por lo que podríamos hacer alusión a la primera premisa, que dice así: Cuando hagas algo por primera vez, hazlo.

Vamos a por la clase Pajaro:

    public class Pajaro
    {
        public int NumeroPatas { private get; set; }
        public string Especie { private get; set; }

        public int GetNumeroPatas()
        {
            return NumeroPatas;
        }

        public string TipoEspecie()
        {
            return Especie;
        }
    }

Ahora ya tenemos una clase Pájaro también, que usa las mismas propiedades y los mismos métodos. Por lo que vemos que se aplica la segunda premisa: Cuando hagas algo parecido por segunda vez, no te conformes con tener que repetirlo, pero hazlo de todos modos.

En este ejemplo el código es igual, pero podría no serlo, podría ser un código que se puede agrupar, y no necesariamente siempre ha de ser el mismo idéntico.

Veamos la clase Serpiente:

    public class Serpiente
    {
        public int NumeroPatas { private get; set; }
        public string Especie { private get; set; }

        public int GetNumeroPatas()
        {
            return NumeroPatas;
        }

        public string TipoEspecie()
        {
            return Especie;
        }
    }

Una vez más, usamos las mismas propiedades, los mismos métodos, y sería el momento de aplicar la tercera premisa: Cuando hagas algo por tercera vez, empieza a refactorizar.

Pues hagámosle caso y refactoricemos, ya que vemos que tenemos exactamente el mismo código tres veces repetido, por lo que es hora de ponernos manos a la obra, antes no:

    public class Animal
    {
        public int NumeroPatas { private get; set; }
        public string Especie { private get; set; }

        public int GetNumeroPatas()
        {
            return NumeroPatas;
        }

        public string TipoEspecie()
        {
            return Especie;
        }
    }

    public class Pajaro : Animal {}

    public class Gato : Animal {}

    public class Serpiente : Animal {}

    var gato = new Gato
    {
        Especie = "Felino",
        NumeroPatas = 4
    };

Como veréis, hemos creado una clase Animal, de la que heredan, Gato, Pájaro y Serpiente y hacen uso de sus propiedades y métodos, y hemos dejado centralizado el código para su uso en las tres clases. De este modo si en un momento dado, se añade o modifica un método en la clase Animal, este será accesible desde las tres otras y sólo se tendrá que realizar la refactorización en un sitio único.

¿ Habéis aplicado muchas veces vosotros esta regla o la veis útil ? Os leo en comentarios.

Object Mother

Carlos Vigueras — Sat, 05 Sep 2026 07:45:57 +0000

En esta entrada voy a hablar sobre un tema que me parece muy interesante, y aunque no está directamente relacionado con TDD, si lo está con Testing de aplicaciones, y en este caso, como siempre lo voy a orientar a .NET.

El patrón Object Mother, lo presentó Martin Fowler en el año 2006, y los define de una forma clara y sencilla de esta forma:

Desde mi experiencia y punto de vista, yo prefiero usar siempre Object Mother en mi Tests antes que el Patrón Builder, el cual he visto muchas veces a la hora de construir objetos de ejemplo para testear un caso de uso, o cualquier otro tipo de Test.

El Patrón Builder en los test personalmente no me gusta, ya que estamos añadiendo una lógica innecesaria que creo que deberíamos evitar, aunque en contraposición hay muchos expertos que se expresan a favor de usarlos, y como todo en la vida, para gustos los colores.

Una cosa importante a tener en cuenta, es que nuestros Tests nunca deberían aplicar lógica alguna en su implementación, o en todo caso la mínima posible. Porque si aplicamos lógica, ¿quien testea el test?

Aunque con el Patrón Builder, no es que estemos añadiendo una lógica en sí, si que estamos creando una clase específica para construir un objeto determinado y estamos introduciendo complejidad a nuestros Tests.

Con Object Mother, lo que conseguimos es centralizar una serie de objetos con una característica especial y hacer uso de ellos desde diferentes Suites de Tests que implementemos, de esta forma, a la hora de ir creando objetos, no hemos de ir dejando trozos de código repetidos por todos nuestros Tests.

Imaginemos que vamos a comenzar a desarrollar una aplicación que es solo de uso para personas mayores de 18 años, y que dependiendo la edad que tengas, vas a tener acceso a unos descuentos u otro. A la hora de acceder a la aplicación, hemos de realizar las siguientes comprobaciones:

Dado un usuario menor de 18 años, cuando intenta acceder a la aplicación, quiero que se le muestre un mensaje: «Aplicación web solo para personas mayores de edad«.
Dado un usuario mayor de 18 años y menor de 30 acceda a la aplicación, quiero que le muestre un mensaje: «Consigue un descuento de 20€ en tu primer pedido«.
Dado un usuario mayor de 30 años y menor de 65 acceda a la aplicación, quiero que le muestre un mensaje: «Consigue un descuento de 25€ en tu primer pedido«.
Dado un usuario mayor de 65 años acceda a la aplicación, quiero que le muestre un mensaje: «Consigue un descuento de 30€ en tu primer pedido«.

A lo largo de todos nuestros Tests, vamos a necesitar juegos de datos con estos 4 tipos de usuarios, no solo para cuando acceda a la aplicación mostrar el mensaje, si no, posteriormente cuando compre un producto saber que tipo de descuento se le va a aplicar, y para otros muchos casos mas.

Si en todos estos Tests, nos vamos creando para cada uno de ellos una instancia, nos vamos a encontrar con mucho código repetido por todos lados, pero si usamos Object Mother, estos datos los vamos a tener centralizados. Pero sin meter mas rollo, vamos a ver un ejemplo con .NET y NUnit, y esta vez, aparte de exponeros el código, os referenciaré el GitHub asociado hecho con TDD:

Clase User.cs

    public class User
    {
        public string Name { get; set; }
        public int Age { get; set; }

        public User(string name, int age)
        {
            Name = name;
            Age = age;
        }
        public static User Create(string name, int age)
        {
            return new User(name, age);
        }
    }

Clase Home.cs

    public class Home
    {
        public string Access(User user)
        {
            switch (user.Age)
            {
                case < 18:
                    return "Aplicación web solo para personas mayores de edad";
                case < 30:
                    return "Consigue un descuento de 20€ en tu primer pedido";
                case < 65:
                    return "Consigue un descuento de 25€ en tu primer pedido";
                case > 65:
                    return "Consigue un descuento de 30€ en tu primer pedido";
                default:
                    return string.Empty;
            }
        }
    }

Suite de Tests UserShould.cs

public class UserShould
{
    private Home home;
    [SetUp]
    public void Setup()
    {
        home = new Home();
    }

    [Test]
    public void get_message_under_eighteen_years()
    {
        //Given
        var givenUserUnderEighteen = User.Create("Pepito Grillo", 16);

        //When
        var message = home.Access(givenUserUnderEighteen);

        //Then
        Assert.IsTrue(string.Equals(message, "Aplicación web solo para personas mayores de edad", 
            StringComparison.OrdinalIgnoreCase));
    }

    [Test]
    public void get_message_over_eighteen_under_thirty_years()
    {
        //Given
        var givenUserOverEighteenUnderThirty = User.Create("Pepito Grillo", 29);

        //When
        var message = home.Access(givenUserOverEighteenUnderThirty);

        //Then
        Assert.IsTrue(string.Equals(message, "Consigue un descuento de 20€ en tu primer pedido",
            StringComparison.OrdinalIgnoreCase));
    }

    [Test]
    public void get_message_over_thirty_under_sixty_five_years()
    {
        //Given
        var givenUserOverThirtyUnderSixtyFive = User.Create("Pepito Grillo", 46);

        //When
        var message = home.Access(givenUserOverThirtyUnderSixtyFive);

        //Then
        Assert.IsTrue(string.Equals(message, "Consigue un descuento de 25€ en tu primer pedido",
            StringComparison.OrdinalIgnoreCase));
    }

    [Test]
    public void get_message_over_sixty_five_years()
    {
        //Given
        var givenUserOverSixtyFive = User.Create("Pepito Grillo", 67);

        //When
        var message = home.Access(givenUserOverSixtyFive);

        //Then
        Assert.IsTrue(string.Equals(message, "Consigue un descuento de 30€ en tu primer pedido",
            StringComparison.OrdinalIgnoreCase));
    }
}

Si os fijáis en la Suite de Tests de UserShould.cs, para cada uno de los test he ido llamando al método Create de User, y he ido creando un usuario con diferentes edades que necesito para realizar el testeo, y sí, podría llevámerlo a un método en la misma Suite, donde se le pasase un nombre y una edad y me retornase el objeto, pero de esta forma, los tests no quedan claros, no se ve a simple vista que es lo que se quiere realmente testear (tal vez en este ejemplo si, en otros mas complejos, creedme que no).

Los Tests han de servirnos de documentación, por eso es muy importante tener unos Tests claros y concisos, que se expresen por si solos y nada mas verlos, sepamos cual es su propósito.

Si en vez de ir creando un objeto en cada uno de los Tests, nos creamos un Objeto Madre u Object Mother centralizado, vamos a pedirle y recibir exactamente lo que necesitamos, eso sí, siempre usando un nombre de método declarativo y que exprese que es lo que devuelve. Veamos como quedaría la Suite de Tests y el Objeto Madre:

UserShould.cs

    public class UserShould
    {
        private Home home;
        [SetUp]
        public void Setup()
        {
            home = new Home();
        }

        [Test]
        public void get_message_under_eighteen_years()
        {
            //Given
            var givenUserUnderEighteen = UserMother.UserUnderEighteen();

            //When
            var message = home.Access(givenUserUnderEighteen);

            //Then
            Assert.IsTrue(string.Equals(message, "Aplicación web solo para personas mayores de edad",
                StringComparison.OrdinalIgnoreCase));
        }

        [Test]
        public void get_message_over_eighteen_under_thirty_years()
        {
            //Given
            var givenUserOverEighteenUnderThirty = UserMother.UserOverEighteenUnderThirty();

            //When
            var message = home.Access(givenUserOverEighteenUnderThirty);

            //Then
            Assert.IsTrue(string.Equals(message, "Consigue un descuento de 20€ en tu primer pedido",
                StringComparison.OrdinalIgnoreCase));
        }

        [Test]
        public void get_message_over_thirty_under_sixty_five_years()
        {
            //Given
            var givenUserOverThirtyUnderSixtyFive = UserMother.UserOverThirtyUnderSixtyFive();

            //When
            var message = home.Access(givenUserOverThirtyUnderSixtyFive);

            //Then
            Assert.IsTrue(string.Equals(message, "Consigue un descuento de 25€ en tu primer pedido",
                StringComparison.OrdinalIgnoreCase));
        }

        [Test]
        public void get_message_over_sixty_five_years()
        {
            //Given
            var givenUserOverSixtyFive = UserMother.UserOverSixtyFive();

            //When
            var message = home.Access(givenUserOverSixtyFive);

            //Then
            Assert.IsTrue(string.Equals(message, "Consigue un descuento de 30€ en tu primer pedido",
                StringComparison.OrdinalIgnoreCase));
        }
    }

UserMother.cs

    public class UserMother
    {
        public static User UserUnderEighteen()
        {
            return User.Create("Pepito Grillo", 16);
        }

        public static User UserOverEighteenUnderThirty()
        {
            return User.Create("Pepito Grillo", 29);
        }

        public static User UserOverThirtyUnderSixtyFive()
        {
            return User.Create("Pepito Grillo", 46);
        }

        public static User UserOverSixtyFive()
        {
            return User.Create("Pepito Grillo", 67);
        }
    }

Como podéis ver ahora tenemos un Objeto Madre UserMother, con métodos que devuelven diferentes tipos de usuarios, de diferentes edades según necesitemos y con unos nombres de métodos que expresan exactamente que es lo que devuelven, por lo que en los Tests hacemos alusión a esos métodos dependiendo lo que necesitemos, si es un usuario menor de 18, mayor de 18 y menor que 30… etc.

De esta forma hemos centralizado la creación de los datos, y no solo eso, si no que en los Tests, se ve de una forma mas sencilla que es lo que pretende dicho Test, además, tenemos el código mas ordenado, mas limpio, mas entendible, centralizado y legible.

Os dejo el repositorio de Github que he creado con el ejemplo completo.

¿Vosotros preferís Object Mother o Patrón Builder? Os leo en comentarios!

Conclusiones sobre Object Calisthenics

Carlos Vigueras — Sat, 05 Sep 2026 07:45:39 +0000

Para finalizar, me gustaría sacar unas conclusiones personales sobre Object Calisthenics, en base a cómo a mi me han servido en el desarrollo de mis funciones profesionales, como las he ido aplicando y como he llegado a interiorizarlas de una forma que cada vez que desarrollo algo nuevo, o veo un código ya realizado, visualizo de una forma rápida el como aplicarlas.

Como comenté en la primera entrada de todas de Introducción a Object Calisthenics, este lo podemos definir como:

“Ejercicios de programación que te pueden ayudar a interiorizar las bases de un buen diseño orientado a objetos“.

Y al fin y al cabo es así, yo comencé aplicando estas 9 reglas en base a Katas, y fui poco a poco practicando hasta que llegué a interiorizarlas y poder ponerlas en práctica en código productivo.

Una buena página de recursos de Katas es Kata-Log-Rocks, la cual os animo a que visitéis y podáis practicar lo máximo posible, ya que este tipo de ejercicios están muy bien pensados para practicar la detección y refactorización de Code Smells o TDD, o un sin fin de técnicas que nos ayudaran a mejorar como programadores, ya que como todo en la vida es cuestión de práctica.

Como habréis visto en esta 9 nueva entradas de Object Calisthenics, este al final siempre se basa en crear, o refactorizar un código mas legible, entendible y claro, afianzando la encapsulación de objectos, y el principio de responsabilidad única.

Desde mi punto de vista todo esto es muy importante para tener un código mas mantenible, y eso nos hará la vida mucho mas fácil.

Con esta entrada, lo único que pretendo es a animaros a que los que no estéis muy familiarizados en aplicar estas 9 reglas, practiquéis y lleguéis a interiorizarlas tanto o mas como yo lo he hecho.

Y que siempre tengáis en cuenta, que no hay que tomarlas en todos los casos al pie de le letra, hay que aplicarlas con sentido común adaptándonos al problema que en cada momento se nos presente.

Mis próximas entradas me gustaría comenzar a hablar sobre TDD.

Pero de todos modos me gustaría que me dejéis en comentarios si preferís que hable de cualquier otro tema, y si mas o menos lo domino os tomaré la palabra.

Como siempre gracias a los que me leéis!

Evitar getters/setters o atributos públicos

Carlos Vigueras — Sat, 05 Sep 2026 07:45:29 +0000

En esta entrada voy a explicar la última regla, la número 9 para ser mas exactos de Object Calisthenics, la cual, para mi es muy importante.

Para aplicar bien esta regla, hay tener en cuenta, que nuestros objetos deben siempre estar encapsulados y no permitir el acceso a los mismos de una forma directa, ya que si no se encapsulan de una forma correcta podremos acceder a ellos desde diferentes partes del código y esto va a generar un código poco limpio, poco entendible, y sobre todo poco mantenible.

Y no solo eso, si no que estaremos creando objetos o entidades no inmutables, y en cualquier momento se podrán modificar de forma deliberada sin control ninguno por nuestra parte.

Estaremos permitiendo modificar el valor de una variable sin una posible validación añadida en la creación del objeto, y como he dicho anteriormente, no estaremos respetando la inmutabilidad.

Cualquier programador que desarrolle en el mismo código, podrá tener acceso a esa variable y alterar su valor, y esto nos podrá generar una serie de errores incontrolados, que seguro ninguno de nosotros deseamos.

Esta regla, básicamente, se refiere a que debemos encapsular nuestros objetos, y de esta forma que sean inmutables, que como siempre digo, no hay que tomarse las cosas al pie de la letra, pero en mi opinión es que nos ciñamos lo máximo posible y la cumplamos, aplicando lo que se denomina «Tell, don’t ask».

Voy a comenzar una breve explicación, comenzando por los métodos Setters y posteriormente iré a los Getters.

Setters

Si en cualquier parte del código de nuestra aplicación permitimos establecer el valor de una variable, estamos permitiendo que el acceso no esté centralizado en un solo lugar, por lo tanto estaremos ante la situación de un Code Smell que se denomina Shotgun Surgery, y aunque no sea el propósito del post, voy a explicar que es el Shotgun Surgery:

Cuando el valor de una variable se puede establecer desde diferentes sitios, o acceder a su valor, o cuando una función o método no están centralizados, hemos de replicar código repetido por toda nuestra aplicación, y el código repetido es un serio problema a la hora de refactorizar, ya que en el mejor de los casos, aunque tengamos unas buenas Suites de Tests no vamos a llegar a cubrir todos los casos que han sido modificados.

Si en este caso que comento se ha de realizar algún tipo de refactorización, bien sea el cambio de un tipo de una variable, o bien sea la modificación de un proceso, si estos no están centralizados, tendremos que ir por todo el código buscando donde está esa lógica aplicada y aplicar este cambio en todas las partes donde lo encontremos, por lo que seguramente se nos olvidará algún sitio donde modificarlo y estaremos dejamos un trozo de código sin modificar, generando futuros errores.

Y aunque en el caso de .NET, en el cambio de un tipado de variable, el compilador nos va a indicar un error, no en todos los lenguajes de programación, ni en todos los compiladores se comporta igual.

Y esto es Shotgun Surgery, sobre el que escribiré en una futura entrada, pero sigamos a lo nuestro, que no quiero desviarme del tema.

Getters

Las variables no deberían siempre por defecto estar expuestas para acceder a su valor directamente, si no que deberíamos crear métodos en los objetos que ofrezcan comportamientos del objeto con el que estamos trabajando, aunque para mi gusto, personalmente en muchas ocasiones prefiero utilizar un método Get o dejar la propiedad libre para ser leída, ya que si no vamos a generar una complejidad y código innecesario en la clase, pero esto lo veremos en un ejemplo, ya que es mas fácil de transmitir la idea.

Vamos a ver un ejemplo de implementación con Getters y Setters y posteriormente su refactorización, y para ello nos vamos a centrar sólo en la clase Robot() modificándola y obviando todas las demás clases, así podremos ver el ejemplo mas simplificado:

public class Robot
{
    public string Name { get; set; }
    public Position Position { get; set; }

    public Robot()
    {
        Position = new Position(0, 0);
    }

    public void SetPosition(Position position)
    {
        if (position is { X: > 0, Y: > 0 })
        {
            Position = position;
        }
    }

    public Position GetPosition()
    {
        return Position;
    }
}

En esta clase Robot(), vemos que tenemos dos métodos, SetPosition(), que recibe una posición y se la establece a Robot(), y por otro lado un método GetPosition(), el cual devuelve la posición del Robot(), y como variable del objecto tenemos Position establecido con su get y su set correspondiente.

No estamos encapsulando nada, si que es cierto que ponemos un método GetPosition() a disposición de quien quiera usarlo, pero tambien podemos hacer un Robot.Position y acceder a su posición, por lo que de este modo no tenemos nada encapsulado. Además no es responsabilidad de Robot() establecer la posición, aunque para este ejemplo lo haya puesto así.

Si os fijáis en el método SetPosition(), establecemos una posición y posteriormente deberíamos acceder a Robot.Position para saber cual es su posición actual, por lo que estamos exponiendo nuestro objeto, ya que se podría hacer un Robot.Position = new Position(1,2) y modificaríamos su posición sin hacer alusión alguna al método Set que hemos establecido, y por lo tanto no se aplicaría la validación de que las posiciones no fuesen negativas.

Lo mismo aplicaría para Name, ya que para un Robot() que hemos creado le podríamos cambiar el nombre a nuestro antojo en cualquier momento.

Aquí rompemos totalmente la encapsulación y dejamos a merced de cualquiera modificar nuestro objeto como se le antoje creando errores en nuestro flujo, ya que podríamos mover a Robot() a unas posiciones negativas que no existen.

Vamos a ver como se debería quedar la clase Robot() bajo mi punto de vista, ya que esto puede ser llevado a miles de interpretaciones diferentes:

    public class Robot(string name)
    {
        public string Name { get; } = name;
        public Position Position { get; private set; } = new(0, 0);

        public Position Move(Position position)
        {
            if (position is { X: > 0, Y: > 0 })
            {
                Position = position;
            }
            return Position;
        }
    }

var robot = new Robot("Pepito Grillo");
var position = robot.Position;
var name = Robot.Name;
var positionMoved = robot.Move(new Position(5, 9));

Comenzando a analizar la refactorización, voy a empezar por Position, la cual ahora es controlada por un método de Robot().Move(), y lo que hace es mover al Robot() a una posición dada y devolver la nueva Position, por lo que aquí ya tenemos un método de comportamiento y no un Set, que lo que solo hace es devolver la posición.

¿ Pero necesariamente para conocer la posición del Robot() he de moverlo ?

¿ No puedo conocer la posición de Robot() en un momento dado sin mas ?

Pues aquí es donde yo quería llegar, y dar mi opinión en base a esto. Bajo mi punto de vista, no siempre creo que sea necesario crear un método de comportamiento, si en mayor medida para un método Set, pero no tanto para un método Get, es más, soy partidario de simplemente, tal y como he hecho en el ejemplo de refactorización, dejar que la variable que se desee consultar sea accesible para su lectura, ya que por ejemplo con la variable Name sucede lo mismo.

¿Acaso podemos crear un método de comportamiento para una variable de Nombre ?

Yo no le veo sentido alguno, ni para conseguir el Name en un momento dado ni para conseguir la Position, y añadir un método Get para conseguirlos me parece innecesario. Pero esta es mi aproximación, no digo que sea la mas correcta.

¿ Cómo lo harías vosotros ? Os leo en comentarios!

Evitar más de dos atributos de instancia.

Carlos Vigueras — Sat, 05 Sep 2026 07:45:15 +0000

Bueno, pues una vez más, vamos a ver una regla de Object Calisthenics, que veremos que vuelve a está relacionada directamente con la responsabilidad única, es la de «Evitar más de dos atributos de instancia«.

Esta regla nos viene a decir que las clases deben ser responsables del manejo de una única variable de instancia, aunque algunas requerirán de dos, y con esto reduciremos la cohesión de dicha clase. Muchas veces comenzamos a declarar una clase introduciendo una gran cantidad de variables sin pararnos a pensar de que forma podemos disociar estas, y sin tratar de separar responsabilidades, y con esto lo que estamos haciendo es mezclar responsabilidad, y haciendo que una clase haga mas cosas de las que realmente debería hacer.

Como ya he comentado en muchísimas ocasiones, no debemos tomarnos esto al pie de la letra, ya que siempre no está de nuestro lado tomar esta decisión de una forma directa, como por ejemplo en entidades que ya nos vienen supeditadas por como esté estructurada la base de datos, y ahí si se nos puede dar un claro caso de manejar una gran cantidad de variables, y aunque aquí también podríamos separar responsabilidades no es el caso en el que nos estamos centrando.

Aunque mi opinión es que si debemos ceñirnos en la mayoría de lo posible a esta caso y tratar de separar las responsabilidades de la clase, ya que de este modo se nos quedará una clase mas clara, entendible y por norma general con no mas de 50 líneas, como se ha visto en la entrada anterior.

Veamos un ejemplo volviendo a los Robots:

Tal y como hablábamos en la entrada anterior con el ejemplo de la recolección de Basura por parte de los Robots, seguimos teniendo la clase Robot, pero ahora hemos dicho que recolectan Basura que depositan en un Centro de reciclado.

Se nos podría quedar una clase de este estilo de primeras sin pensar en separar responsabilidades:

    public class Robot
    {
        public string Name { get; set; }
        public Position Position { get; set; }
        public List<string> Basura { get; set; }
        public string NombreCentroReciclado { get; set; }
        public string DireccionCentroReciclado { get; set; }

        public Robot()
        {
            Position = new Position(0, 0);
        }
    }

    var robot = new Robot
    {
        Name = "Pepito Grillo",
        Basura = new List<string> { "bote refresco", "bolsa pipas", "botella agua" },
        DireccionCentroReciclado = "Poligono Industrial Recycling",
        NombreCentroReciclado = "Reciclando S.A."
    };

En este ejemplo vemos como Robot() tiene por un lado una variable Name, para el nombre del Robot, también Basura, que es una lista con toda la basura que ha recogido, la DireccionCentroReciclado, y el NombreCentroReciclado, para este caso a Robot le estamos dando la responsabilidad, no solo de conocer donde está el centro de reciclado y su Nombre, si no de asignar esa dirección y ese nombre del centro, y Robot() no debería encargarse de realizar ese tipo de asignación.

Si en un futuro quisiéramos validar que la dirección del centro de reciclado o si su nombre es correcto, debería hacerlo Robot(), ya que está en su clase, y el tampoco ha de validar esto, y esta es la forma en la que una clase se nos podría hacer muy larga, o haría muchas mas cosas de las que debe y no sería ni clara, ni legible ni fácilmente entendible.

Para evitar este problema hemos de refactorizar la clase, vamos a hacerlo y a explicar el por qué hacerlo así:

    public class Robot
    {
        public string Name { get; set; }
        public Position Position { get; set; }
        public CentroReciclado CentroReciclado { get; set; }

        public Robot()
        {
            Position = new Position(0, 0);
        }
        public void DepositarBasura(string basura)
        {
            CentroReciclado.RecibirBasura(basura);
        }
    }

    var centroReciclado = new CentroReciclado()
    {
        Nombre = "Reciclando S.A.",
        Direccion = "Poligono Industrial Recycling",
    };
    var robot = new Robot
    {
        Name = "Pepito Grillo",
        CentroReciclado = centroReciclado,
    };
    robot.DepositarBasura("botella agua");

Con esta refactorización podemos ver que hemos sacado de la ecuación de Robot a Basura, y hemos convertido las variables de NombreCentroReciclado y DireccionCentroReciclado en la clase CentroReciclado, por lo que esta nueva clase se nos ha quedado de esta forma:

    public class CentroReciclado
    {
        public string Nombre { get; set; }
        public string Direccion { get; set; }
        private Basuras Basuras { get; set; }

        public CentroReciclado()
        {
            Basuras = new Basuras();
        }

        public void RecibirBasura(string basura)
        {
            Basuras.Add(basura);
        }

        public void Recicla()
        {
            if (Basuras.values.Count > 10)
            {
                Basuras.EstadoBasuras = EstadoBasuras.Reciclada;
            }
        }
    }

    public class Basuras
    {
        public List<string> values { get; set; }
        public EstadoBasuras EstadoBasuras { get; set; }

        public Basuras()
        {
            values = new List<string>();
        }

        public void Add(string value)
        {
            values.Add(value);
        }
    }

    public enum EstadoBasuras
    {
        Default = 0,
        SinReciclar = 1,
        Reciclada = 2,
    }

Con esto hemos conseguido refactorizar la clase Robot(), para que tenga, en este caso menos variables de Instancia en la clase de las que antes tenía, hemos reducido la cohesión de la clase. Se ha pasado responsabilidad a quien realmente la tiene y las validaciones como la que vemos en el método Recicla() han pasado a ser responsabilidad de la clase CentroReciclado().

Personalmente a mi me parece una de las reglas mas difícil de explicar y sobre todo de cumplir, y creo que lo mas importante aquí no es el tener dos variables de instancia, o tres o cuatro, para mi lo mas importante es saber delegar la responsabilidad a la clase propia.

En un plano idílico si tendríamos solo dos variables de instancia por clase, pero esto en la mayoría de casos cumplirlo es muy complejo, por ese motivo he querido seguir aplicando el ejemplo de Robot(), hubiera sido mas fácil aplicar esta regla con el típico ejemplo de Nombre y Apellidos, pero quería tratar de plasmar con una clase un poco mas compleja, lo realmente complicada que puede hacerse esta regla cuando una clase está mas ligada a un Negocio, y sobre todo si en un momento dado este está muy acoplado.

Y esto no quiere decir que en este ejemplo no pudiéramos cumplir la regla, habría que refactorizar bastante el código, pero podríamos perfectamente adaptarnos a cumplirla.

¿ Hasta que punto pensáis que esta regla hemos de cumplirla al pie de la letra ? Os leo en comentarios!!