Tweet

¿Estás escribiendo una especificación de prueba?

Hay varias formas de redactar especificaciones de prueba, como hacerlas como especificaciones de prueba o como código de prueba, dependiendo de la empresa. Creo que es común que las empresas grandes y históricas creen especificaciones de prueba en archivos de Excel. Al editar entre varias personas, creo que también es común, al menos en Japón, utilizar sufijos como _latest, _latest_20230103, _latest_5 para gestionar las versiones.

Me gustaría conocer las mejores prácticas para manejar archivos de Excel, pero no tengo una buena idea en este momento, así que decidí utilizar un programa para hacer que las diferencias sean visibles en un repositorio Git y gestionarlas.

Sin embargo, si colocas el archivo de Excel directamente en Git, las líneas de diferencia no se mostrarán claramente. TortoiseGit y otras herramientas también te mostrarán la diferencia, pero ¿puedes hacer pull requests y comentarios allí? Normalmente ves la diferencia en la página web del repositorio de todos modos. Y CSV también es un poco insatisfactorio. Hay herramientas que pueden editar CSV en formato de tabla como hoja de cálculo, pero la visualización de diferencias en el repositorio debería ser un texto delimitado por caracteres simple, que no es fácil de leer.

Entonces, pensé en gestionar casos de prueba en Markdown. Si puedes gestionarlo en texto, también puedes usar comandos *nix. Puedes escribir casos de prueba incluso si no tienes Excel, y si puedes convertirlo a Excel, nadie tendrá problemas. (La herramienta que utilicé también puede convertir a CSV, TSV.)

Tweet