8/2/2025

Muchos curiosos se han cuestionado en diversas ocasiones la verdadera naturaleza de los elementos de prueba, ¿de dónde proviene esta vagancia a la hora de probar nuestros entornos?

Muchos curiosos se han cuestionado en diversas ocasiones la verdadera naturaleza de los elementos de prueba. Todos sabemos que los elementos de prueba son elementos sencillos y fáciles de generar que permiten a un desarrollador poner a prueba un entorno sin realizar mucho esfuerzo. Ahora bien, ¿de dónde proviene esta vagancia a la hora de probar nuestros entornos? ¿Cuál fue el primer elemento de prueba de la historia de la programación? ¿Deberíamos hacer nuestros elementos de prueba sin esfuerzo? Todas estas preguntas y muchas más serán respondidas a lo largo de este artículo.

Del asdfasdf al lorem ipsum. ¿Qué es un texto de prueba?

Llamo elementos de prueba a todos aquellos elementos (textos, imágenes, audios, etc.) que se utilizan para poner a prueba un programa o entorno recientemente desarrollado. En inglés, la palabra placeholder representa perfectamente este concepto: un elemento de prueba nos "guarda" el lugar hasta que lo completemos con lo que realmente le corresponde en un futuro. Suele ser su rápida fabricación lo que más atrae a los desarrolladores, pues les permite poner a prueba sus programas sin tener el contenido finalizado.

En este artículo nos vamos a enfocar en los textos de prueba, que son aquellos elementos de prueba con forma de strings o cadenas de caracteres. Para poder entenderlos mejor vamos a diferenciar tres tipos de textos de prueba muy comunes a la hora de desarrolar aplicaciones.

Textos de debuggeo: print("hola")

Todo programador avezado sabe que, en el fondo, la programación no es más que debuggeo tapado con un sobretodo de informática y sintaxis. Muchas veces, a la hora de debuggear, necesitamos ver el funcionamiento de nuestro código, para lo cual recurrimos a la consola. Aquí, podemos imprimir cualquier tipo de mensajes que nos informe el estado de nuestro código. Y es acá cuando nosotros, los desarrolladores carentes de imaginación, usamos letras o palabras aleatorias para nuestros mensajes. A lo largo de mi vida como programador, me he encontrado con ejemplos verdaderamente absurdos (que yo mismo he usado). Algunos de mis favoritos:

• print("queso")
• print("funciona! :)")
• print("no funciona :(")
• print("LPM NO TENÉS QUE ENTRAR ACÁ >:(")

Si bien algunos de estos son, digamos, bastante representativos, considero mínimo el esfuerzo a realizar para conseguir unos mensajes de debuggeo aceptables. Además, todo sea por el bien del debug... de la programación. ¿No es así?

Textos de usuario: ¡Hola, asdfasdf!

Una de las situaciones más divertidas y es absurdas en las que se suele encontrar desarrollador es la personificación de los usuarios. La razón es clara: los usuarios pueden ser increíblemente estúpidos. No importa cuán enrevesada sea la secuencia de pasos para llegar a un error, pues si este existe, el usuario se las apañará para llegar a él. Pero no es de la estupidez del usuario, sino de la parquedad del desarrollador de la que quiero hablar en esta ocasión. Y el desarrollador puede ser un verdadero idiota a la hora de "hacerse el usuario".

¿Por qué somos tan insensibles que, a la hora de ponernos en los zapatos de un usuario, utilizamos nombres tan absurdos como asdfasdf? ¿De verdad así de estúpidos vemos a los usuarios? Este tipo de minimización del usuario puede ser un arma de doble filo, solo que con los dos filos hacia nuestro cuerpo. No solo es una representación que nos resulta ofensiva a los usuarios (me incluyo en este grupo también), sino nuestro código fue probado bajo situaciones exclusivamente irreales e improbables. Y este último hecho no es menor, pues puede acarrear problemas a la hora de exponer nuestro código al mundo real. Y la solución es tan sencilla como poner tu nombre ahí...

Textos de diseño: sed ut perspiciatis, unde omnis iste natus error

Cuando un diseñador quiere poner a prueba cualquier página que pretenda muestre textos, necesita, justamente, un texto que mostrar. Esto puede ser crucial, ya que muchas veces fallas de diseño solo se vuelven visibles al poner a prueba nuestra plantilla con contenido de verdad. Ahora bien, ¿va el diseñador a escribir un texto de verdad, con la longitud necesaria -generalmente, mucha- para poder poner a prueba sus plantillas? Respuesta corta: no.

Respuesta larga: ni en pedo, ¿vos estás loco?

Esta es la triste situación en el que se encuentra nuestra comunidad desarrolladora. Infinidad de generadores de lorem ipsum automáticos para evitar este tedioso paso clave para el trabajo de cualquier diseñador. Sin embargo, yo creo que, además de que esta solución padece de los mismos problemas planteados en las pruebas de usuario, existe una razón más profunda para alejarnos de este vicio: el amor.

Todo buen desarrollador ama a sus programas al igual que todo buen padre ama a sus hijos. De este modo, por qué someter a nuestros hijos a tan descuidado trato automatizado. ¿Dejaríamos que un robot cuidador cuya procedencia desconocemos se haga cargo de nuestro niño mientras trabajamos en otras cosas? Si no, entonces, ¿por qué le insertaríamos a nuestro código un texto autogenerado, cuya procedencia ni siquiera conocemos? Porque, a ver, ¿quién conoce el lorem ipsum? Sí, podemos saber que son palabras recortadas de una obra de Virgilio¹, en latín. ¿Pero qué obra? ¿Qué significan esas palabras? ¿Estamos de acuerdo con su mensaje?

Quiero aclarar que esto no es una campaña de desprestigio al lorem ipsum ni mucho menos. Por el contrario, es una campaña de incentivo a la invención de textos propios a la hora de poner a prueba un diseño. De hecho, este mismo texto no es más que eso: un simple relleno para comprobar que los artículos de la página se muestran como yo quería.

La naturaleza de los textos de prueba

A la luz de estas descripciones, nos encontramos en condiciones de describir a los textos de prueba. Estos están, por definición, destinados a la marginalidad. Son embriones poco cuidados y malformados para ocupar provisionalmente el lugar que le destinamos a algo mejor. Y ellos lo saben. Son conscientes de su propia insignificancia, y por eso aceptan su minimizada posición.

Esta es la triste realidad en la que se encuentran los pobres textos de prueba. Y la solución es un sentimiento que todos los programadores, como humanos -sí, somos humanos-, tenemos: el amor. Amemos a nuestros textos de prueba. Expandámonos. Desperdiciemos horas de nuestra vida en ellos. Hagamos del lugar que ellos aguantan el lugar más feliz del mundo. Todo sea por los textos de prueba.

Notas al pie

¹ En realidad, estuvo fue por Cicerón y no por Virgilio. Si no lo sabías y creíste lo que dije, no te juzgo, la gran mayoría de los diseñadores ni conocen el engendro al que exponen sus creaciones. El texto es un collage de recortes del libro De finibus bonorum et malorum, conocido básicamente por ser el origen del lorem ipsum. El texto comienza en la sección 1.10.32 de este libro, cuyo comienzo es el subtítulo de este apartado. El significado de las palabras recortadas, aunque intraducible debido a las mutilaciones, podría traducirse así:

Las opiniones son de cada uno...