Simplifique las pruebas unitarias de Swift con funciones puras ☁️

Esta publicación se centrará en cómo las funciones puras de Swift pueden ayudarlo a escribir pruebas unitarias más efectivas para su aplicación iOS. Sin embargo, me gustaría comenzar con una breve historia de fondo sobre cómo nuestro equipo descubrió estos beneficios.

Trabajé en el equipo de iOS de Salesforce Events de 2016 a 2020. Durante este tiempo, comenzamos a actualizar nuestra base de código de Objective-C a Swift. Al principio de este proceso, decidimos que también queríamos adoptar principios reactivos funcionales que fueran posibles gracias a las funciones de primera clase de Swift.

A medida que trabajábamos en la migración de Objective-C a Swift, nos dimos cuenta de la naturaleza transformadora provocada por las funciones de primera clase. A medida que aumentaba esta conciencia, nuestro esfuerzo dejó de ser una migración de código línea por línea entre Objective-C y Swift. En cambio, comenzamos a centrarnos en la mejor manera de utilizar las funciones de primera clase para crear una mejor aplicación para nuestros usuarios.

Después de un tiempo, nos decidimos por algunos principios rectores que se pueden resumir en:

1. Mantener nuestras funciones puras
2. Minimizar el estado que tienen nuestras clases

Al final, estos principios ayudaron a reducir nuestra tasa de fallas, aumentaron nuestra velocidad de desarrollo, mejoraron el rendimiento de la aplicación y facilitaron la prueba unitaria de nuestro código.

En este artículo, me centraré en los detalles de por qué las funciones puras pueden mejorar el impacto de las pruebas unitarias.

¿Qué son las funciones puras?

1. Una función es pura si siempre devuelve el mismo valor para un conjunto dado de entradas
2. Una función pura está libre de efectos secundarios.

Los efectos secundarios son lecturas o escrituras en el estado fuera del conjunto de parámetros de entrada de la función.

Aquí hay un ejemplo de una función impura que produce la suma de dos números.

Un ejemplo puro, que cumple con nuestros dos criterios anteriores, devuelve el mismo resultado para una entrada dada y no tiene efectos secundarios.

Costo por prueba

Comencemos definiendo lo que quiero decir con "costo" cuando se trata de pruebas unitarias. En este artículo, el "costo" de la prueba es una medida del esfuerzo necesario para escribir una prueba unitaria. Los dos ejemplos a continuación mostrarán la diferencia de costo relativo para probar funciones puras y no puras.

Dadas las funciones de ejemplo anteriores, la prueba de pureAdd se puede realizar de forma compacta. Esto se debe a que escribir una prueba que empareja una entrada con su salida esperada es muy fácil. En estos casos, no se requiere simulación ni inicialización de estado.

Sin embargo, el ejemplo no puro requiere más configuración por afirmación.

En general, cuantos más efectos secundarios tenga una función, mayor será el costo por prueba.

Prueba de efectividad de funciones puras

El objetivo de las pruebas unitarias debe ser probar que la función bajo prueba produce la salida correcta para el espacio de entrada.

Para la función isTrue(input: Bool) → Bool , el espacio de entrada tiene dos posibilidades: verdadero y falso.

Entonces, para probar la corrección, necesitaremos dos afirmaciones:

Si agregamos un segundo parámetro de Bool, duplicamos el espacio de entrada y duplicamos el número de afirmaciones necesarias para probar la corrección:

Para funciones puras, el número de afirmaciones necesarias para probar la corrección es un producto del espacio de entrada. Esto significa que limitar el espacio de entrada ayuda a reducir el esfuerzo de prueba para probar la salida correcta para todas las entradas.

Para reducir el espacio de entrada, debemos favorecer el uso de parámetros de entrada con un número discreto de valores posibles. Por ejemplo, considere usar enumeración frente a Cadena cuando sea posible porque una enumeración tiene un conjunto finito de valores mientras que una Cadena tiene un número ilimitado de valores posibles.

Prueba de efectividad de funciones no puras

Para funciones no puras, probar la salida correcta para el espacio de entrada es considerablemente más desafiante por varias razones:

1. La entrada en una función no pura puede incluir un objeto y un estado global
2. Este espacio de entrada ampliado aumenta el número de afirmaciones necesarias para probar la corrección
3. Como se vio anteriormente, el costo del andamiaje por prueba suele ser más alto para estas funciones
4. El estado compartido puede cambiar externamente antes de que se complete la función

Dado el mayor esfuerzo requerido, probar la corrección puede volverse intratable para estas funciones y, en cambio, apuntamos a la cobertura del código.

Si bien la cobertura es una buena métrica para ayudar a garantizar que las funciones tengan algún nivel de prueba unitaria, no creo que tener cobertura de código sea equivalente a garantizar la corrección de la función.

Pensamientos finales

Este artículo es una introducción a lo que define una función pura y cómo puede aprovechar las funciones puras para amplificar la efectividad de sus esfuerzos de prueba unitaria al demostrar la corrección con un esfuerzo menor.

Aunque me centré en las funciones y pruebas puras de Swift, se pueden obtener muchos más beneficios de la programación funcional y Swift como: concurrencia, reactivo y composición que vale la pena explorar.

Sobre el Autor

Adrian Ruvalcaba es un desarrollador de iOS en el equipo móvil de la aplicación Salesforce. Ha estado obsesionado con el desarrollo móvil desde que se presentó el iPhone. Le gusta especialmente llevar conceptos de programación funcional a dispositivos móviles. Cuando no está programando, Adrian disfruta aprender italiano, español y tomar clases de baile con sus hijos.