Introducción

Hey devs, ahora te traigo un tema relacionado a las pruebas unitarias, algo muy importante por supuesto si eres un desarrollador de software o ingeniero de software, antes era un plus saber hacer pruebas unitarias hace 5 años, ahora es obligatorio si quieres tener éxito, así que en este artículo te diré cómo llamar a las clases y métodos de prueba que hagas. Let's go 🐿️

Las naming conventions o convenciones de nombres en las pruebas unitarias son escenciales para mantener un código claro, legible y mantenible. Un buen nombre de prueba debe describir lo que está siento probado y el resultado esperado, facilitando la comprensión tanto para el desarrollador original como para los futuros miembros del equipo.

Características clave

Sin importar la estrategia que usarás para nombrar a tus clases y métodos de prueba debes seguir estos principios o características clave:

• Claridad: El nombre debe dejar claro el propósito de la prueba nada de hacerte el misterioso jaja.
• Consistencia: Todo el equipo debe seguir la misma convención.
• Legibilidad: Ni demasiado corto porque sería ambiguo ni excesivamente largo (aunque usar nombres largos es normal, aquí se desincentiva nombres excesivamente largo como de 120 caracteres por ejemplo).

Convenciones más utilizadas

Para nombrar tus clases de prueba, es sencillo, generalmente se utiliza NombreClase_Tests o NombreClaseTests o NombreClase.Tests algunos inclusive añaden el namespace al inicio, algo como MyApp.Services.UserService.Tests o alguna de las combinaciones antes descritas.

Entonces podrías tener nombres de clases de pruebas como AuthenticationServiceTests, UserService.Tests, CustomerController_Tests o PersonalManagement.Api.CustomerController_Tests.

Ahora, para nombrar tus métodos de prueba existen estas 3 convenciones las cuales son las más utilizadas en la industria y se consideran buenas prácticas 😉

Given_When_Then

Esta convención proviene de Behavior-Driven Development (BDD) y se utiliza para estructurar pruebas en tres partes claras:

• Given: Es el contexto inicial
• When: Es la acción o evento que se prueba
• Then: Es el resultado esperado

Esta convención es más común encontrarlas en pruebas de aceptación o integración, sin embargo también se aplica en Unit tests. El buen Martín Fowler nos habla de este estilo aquí.

Ejemplo:

public class AuthenticationServiceTests
{
    [Fact]
    public void GivenValidUser_WhenLogin_ThenReturnSuccess() //Given_When_Then
    {
        // Arrange (Given)
        var authenticationService = new AuthenticationService();
        var validUser = new User("username", "validPassword");
        
        // Act (When)
        var result = authenticationService.Login(validUser);
        
        // Assert (Then)
        Assert.True(result.IsSuccess);
    }
}

La implementación del método de prueba es de ejemplo, lo realmente importante es cómo se llama a la clase de prueba y sobretodo al método 😉

Method_Scenario_Result

Esta convención es ampliamente utilizada y es clara y concisa, donde se menciona el método que está bajo prueba es decir la funcionalidad que se está probando, el escenario es decir las condiciones o entradas del test y finalmente el resultado esperado.

Veamos un ejemplo, la misma prueba de antes pero siendo nombrada con esta convención:

public class AuthenticationServiceTests
{
    [Fact]
    public void Login_ValidUser_ReturnsSuccess() // Método_Escenario_Resultado
    {
        // Arrange
        var authenticationService = new AuthenticationService();
        var validUser = new User("username", "validPassword");
        
        // Act
        var result = authenticationService.Login(validUser);
        
        // Assert
        Assert.True(result.IsSuccess);
    }
}

UnitOfWorkName_ScenarioUnderTest_ExpectedBehavior

Esta convención fue planteada por Roy Osherove en su libro "The Art of Unit Testing", tú puedes hallarla en la página 26, a continuación te muestro mejor lo que dijo su mismo creador:

Te recomiendo adquirir el libro y leerlo para tener una mejor idea de los tests unitarios como developer.

Esta estrategia es ampliamente aceptada en la comunidad de desarrollo. Estructura el nombre de la prueba indicando la unidad de trabajo, el estado bajo prueba y el comportamiento esperado.

Si utilizamos esta convención, el mismo método de prueba que venimos utilizando ahora quedaría así:

public class AuthenticationServiceTests
{
    [Fact]
    public void UserAuthentication_ValidUser_ReturnsSuccess() // UnitOfWorkName_ScenarioUnderTest_ExpectedBehavior
    {
        // Arrange
        var authenticationService = new AuthenticationService();
        var validUser = new User("username", "validPassword");
        
        // Act
        var result = authenticationService.Login(validUser);
        
        // Assert
        Assert.True(result.IsSuccess);
    }
}

Errores comunes al nombrar pruebas

• Usar nombres genéricos como Test1(), VerifyMethod(), es tentador pero no lo hagas dev ⛔.
• No describir el comportamiento esperado, no andes con rodeos.
• Usar nombres demasiado largos y aún así sin estructura clara ni entendible.

En conclusión...

Así que ya saben devs, seguir una convención de nombres estándar mejora la comprensión y el mantenimiento del código. Es recomendable elegir una convención y mantenerla consistente en todo el proyecto para garantizar claridad y facilidad de uso.

Usa nombres largos, no está mal, siempre que sean descriptivos, estos deben indicarte a golpe de vista lo que hacen.

Sin embargo ten en cuenta que la decisión de tomar una u otra convención de nombres para Unit Tests es una decisión de equipo, convérsalo con tu equipo de ingeniería y así seguirán las mejores prácticas que hay hoy en día en la industria 😉 y por supuesto compárteles este artículo genio! 🙌

Comparte esta entrada dev! 🔥

Créditos de foto de portada: Foto de Adam Bezer en Unsplash