testing-testing

English | Español

Pruebas y pruebas unitarias

Como habrás aprendido en experiencias de laboratorio anteriores, el lograr que un programa compile es solo una pequeña parte de programar. El compilador se encargará de decirte si hubo errores de sintaxis, pero no podrá detectar errores en la lógica del programa. Es muy importante el probar las funciones del programa para validar que producen los resultados correctos y esperados.

Una manera de hacer estas pruebas es verificando partes del programa “a mano”. Otra manera es insertando pedazos de código o funciones y probando el programa con conjuntos representativos de datos que verifiquen si el programa va haciendo lo que se supone y te ayude a detectar problemas. La biblioteca cassert de C++ tiene funciones para hacer pruebas y en la experiencia de laboratorio de hoy utilizarás una de ellas.

Objetivos:

1. Validar el funcionamiento de varios programas haciendo pruebas “a mano”.
2. Crear pruebas unitarias para validar funciones a partir de su descripción.

Pre-Lab:

Antes de llegar al laboratorio debes:

1. haber repasado los conceptos básicos relacionados a pruebas y pruebas unitarias.

2. haber repasado el uso de la función assert para hacer pruebas.

3. haber estudiado los conceptos e instrucciones para la sesión de laboratorio.

4. haber tomado el quiz Pre-Lab 7 (recuerda que el quiz Pre-Lab puede tener conceptos explicados en las instrucciones del laboratorio).

Sesión de laboratorio:

Ejercicio 1

Este ejercicio es una adaptación del ejercicio en [1]. Se te ha dado un programa que implementa varias versiones de cinco funciones simples, por ejemplo, el juego “piedra-papel-tijera” y el ordenar 3 números. Probando las versiones de cada función, tú y tu pareja determinarán cuál de las versiones está implementada correctamente.

Este ejercicion NO requiere programación, solo pruebas “a mano”. Para este ejercicio no tienes que implementar las pruebas unitarias, solo usa tu habilidad de hacer pruebas a mano.

Por ejemplo, asumamos que una amiga te provee un porgrama. Ella asegura que el programa resuleve el siguiente problema

"dados tres enteros, despliega el valor máximo".

Supongamos que el programa tienen una interfase como la siguiente:

Figura 1 - Interfase de un programa para hallar el valor máximo entre tres enteros.

Podrías determinar si el programa provee resultados válidos sin analizar el código fuente. Por ejemplo, podrías intentar los siguientes casos:

• a = 4, b = 2, c = 1; resultado esperado: 4
• a = 3, b = 6, c = 2; resultado esperado: 6
• a = 1, b = 10, c = 100; resultado esperado: 100

Si alguno de estos tres casos no da el resultado esperado, el programa de tu amiga no funciona. Por otro lado, si los tres casos funcionan, entonces el programa tiene una probabilidad alta de estar correcto.

En este ejercicio estarás validando varias versiones de las siguientes funciones:

• 3 Sorts: una función que recibe tres “strings” o números y los ordena en orden lexicográfico (alfabético). Por ejemplo, dados jirafa, zorra, y coqui, los ordena como: coqui, jirafa, y zorra. Para simplificar el ejercicio, solo usaremos “strings” con letras minúsculas. Otro ejemplo, dados 1, 3 y 2, los ordena como 1, 2, y 3.

  

  Figura 2 - Interfase de la función 3 Sorts.

• Dice: cuando el usuario marca el botón Roll them, el programa genera dos números aleatorios entre 1 y 6. El programa informa la suma de los números aleatorios. Tu tarea es determinar en cuál de las versiones (si alguna) la programadora implementó bien la función de suma.

**Figura 3** - Interfase de la función `Dice`.

• Rock, Papers, Scissors: Cada uno de los jugadores entra su jugada y el programa informa quién ganó. La interfase del juego se muestra en la siguiente figura:

**Figura 4** - Interfase de la función `Rock, Papers, Scissors`.

• Zulu time: Dada una hora en tiempo Zulu (Hora en el Meridiano de Greenwich) y la zona militar en la que el usuario desea saber la hora, el programa escribe la hora en esa zona. El formato para el dato de entrada es en formato de 23 horas ####, por ejemplo 2212 sería las 10:12 pm. La lista de zonas militares válidas la puedes encontrar en http://en.wikipedia.org/wiki/List_of_military_time_zones. Lo que sigue son ejemplos de cómo deben ser los resultados del programa:

  • Dada hora Zulu 1230 y zona A (UTC+1), el resultado debe ser 1330.
  • Dada hora Zulu 1230 y zona N (UTC-1), el resultado debe ser 1130.
  • Puerto Rico está en la zona militar Q (UTC-4), por lo tanto, cuando es 1800 en hora Zulu, son las 1400 en Puerto Rico.
    

  

  Figura 5 - Interfase de la función Zulu time.

Instrucciones:

1. Por favor, asegúrate de que tú y tu apreja de laboratorio entienden las descripciones de las funciones de arriba. Pregúntale a tu instructor de laboratorio si necesitas aclarar algo. Para cada una de las funciones descritas arriba, escribe en tu libreta las pruebas que harás para determinar la validez de las funciones. Para cada función, piensa en los errores lógicos que la programadora pudo haber cometido y escribe una prueba que determine si se cometió ese error. Para cada prueba, escribe los valores que utilizarás y el resultado que esperas obtener.

2. Abre un terminal y escribe el comando git clone https://bitbucket.org/eip-uprrp/lab07-testing.git para descargar la carpeta Lab07-Testing a tu computadora.

3. Haz doble “click” en el archivo testing.pro para cargar este proyecto a Qt.

4. Corre el programa. Verás una pantalla similar a la siguiente:

   

   Figura 6 - Pantalla para seleccionar la función que se va a probar.

5. Selecciona el botón de 3 Sorts y obtendrás la siguiente interfase:

   

   Figura 7 - Interfase de 3 Sorts.

6. La “Version Alpha” en la caja indica que estás corriendo la primera versión del algoritmo 3 Sorts. Usa las pruebas que escibiste en el paso 1 para validar la “Version Alpha”. Luego, haz lo mismo para las versiones Beta, Gamma y Delta. Escribe cuál es la versión correcta en cada una de las funciones. Además, explica las pruebas que realizaste y que te permitieron determinar que las otras versiones son incorrectas.

Por ejemplo, puedes organizar tus respuestas en una tabla como la que sigue:

| 3 Sorts | | | | | | | ------------- | ----------- | ----------- | ----------- | ----------- | ----------- | | Num | Test | Result Alpha | Res. Beta | Res. Gamma | Res. Delta | | 1| “alce”, “coyote”, “zorro” | “alce”, “coyote”, “zorro” | …. | …. | | 2| “alce”, “zorro”, “coyote” | “zorro”, “alce”, “coyote” | …. | …. |

Figura 8 - Tabla para organizar resultados de las pruebas.

Recuerda añadir información que indique cuál(es) de las versiones fueron implementadas correctamente. También recuerda especificar cuáles pruebas te permitieron determinar las versiones que eran incorrectas. Nota: en cada una de las funciones, puede que ninguna versión sea correcta y puede que haya más de una versión correcta.

Puedes ver ejemplos de cómo organizar tus resultados aquí y aquí. Entrega los resultados de este ejercicio en la sección de Entregas del Lab 7 en Moodle.

Ejercicio 2

Hacer pruebas “a mano” cada vez que corres un programa es una tarea que resulta “cansona” bien rápido. Tú y tu pareja lo hicieron para unas pocas funciones simples. !Imagínate hacer lo mismo para un programa complejo completo como un buscador o un procesador de palabras!

Las pruebas unitarias ayudan a los programadores a validar códigos y simplificar el proceso de depuración (“debugging”) a la vez que evitan la tarea tediosa de hacer pruebas a mano en cada ejecución.

Instrucciones:

1. En el menú de QT, ve a Build y selecciona Clean Project "Testing".

2. Ve a la carpeta Lab07-Testing y haz doble “click” en el archivo UnitTests.pro para cargar este proyecto a Qt.

3. El proyecto solo contiene el archivo de código fuente main.cpp. Este archivo contiene cuatro funciones: fact, isALetter, isValidTime, y gcd, cuyos resultados son solo parcialmente correctos. Tu tarea es escribir pruebas unitarias para cada una de las funciones para identificar los resultados erróneos. ** No necesitas reescribir las funciones para corregirlas. **

Para la función fact se provee la función test_fact() como función de prueba unitaria. Si invocas esta función desde main, compilas y corres el programa debes obtener un mensaje como el siguiente:

  Assertion failed: (fact(2) == 2), function test_fact, 

  file ../UnitTests/main.cpp, line 69.

Esto debe ser suficiente para saber que la función fact NO está correctamente implementada. Comenta la invocación de test_fact() en main.

1. Escribe una prueba unitaria llamada test_isALetter para la función isALetter. En la prueba unitaria escribe varias afirmaciones (“asserts”) para probar algunos datos de entrada y sus valores esperados (mira la función test_fact para que te inspires). Invoca test_isALetter desde main. Continúa escribiendo “asserts” hasta que alguno falle. Copia la prueba unitaria test_isALetter y el mensaje de afirmación obtenido en un archivo.

2. Repite el paso 4 paras las otras dos funciones, isValidTime y gcd. Recuerda que debes llamar a cada una de las funciones de prueba unitaria desde main para que corran. Copia cada una de las funciones y los mensajes de afirmación obtenidos en el archivo y entrega el archivo aquí.

Referencias

[1] http://nifty.stanford.edu/2005/TestMe/

English | Español

Testing and Unit Testing

Objectives

Throughout this exercise the students will practice:

• Testing various versions of a program to validate their operation
• Unit Testing

Concepts

As you have learned in previous labs, getting a program to compile is only a minor part of programming. It is super important to test functions in order to validate that they produce the correct results.

Exercise 1

This exercise is an adaptation of [1]. You are provided with a program that implements several versions of five simple functions, e.g. rock-paper-scisors, sorting 3 numbers. By testing the versions, you and your partner will determine which of the versions is correctly implemented.

This first exercise requires NO programming, just testing. For this first exercise, you do not have to implement any unit tests. Just use you testing ability (by hand) to determine which function version is the one that is correctly implemented.

For instance, let us assume that a friend provides you with a program. He claims that his program solves the following problem:

“given three different integers, displays the maximum value”.

Let’s say that the program has an interfaces as follows:

Without analysing the source code, you could determine if the program provides valid results. You could try the following cases:

• a = 4, b = 2, c = 1, expect result: 4
• a = 3, b = 6, c = 2, expected result: 6
• a = 1, b = 10, c = 100, expected result: 100

If any of the three cases fails to give the expected result, you friend’s program is not working. On the other hand, If all three cases are successful, then the program has a high probability of being correct.

In this exercise, you will be validating various versions of the following functions:

• 3 Sorts: a program that receives three strings and sorts them in lexicographical order. For example, given jirafa, zorra, and coqui. Will sort them as: coqui, jirafa, and zorra.

• Dice: when the user presses the Roll them button, the program will generate two random numbers between 1 and 6. The sum of the random numbers is reported.

• Rock, Papers, Scissors: The user enters the play for the two players ( ‘R’ for Rock, ‘P’ for Paper and ’S’ for Scissors) and specifies the number of games needed to win the tournament. The program then reports who won and the score. The program reports if a player wins the tournament.

• Check Writer: The user enters a number between 0 and 999,999,999 (inclusive). The program’s output is a long string version of the number. For example, if the user inputs ‘654123’ the program will output ‘six hundred fifty four thousand one hundred twenty three’.

• Zulu time: given the time in zulu time (Greenwich Mean Time) and the military zone that the user whishes to know, the program outputs the time at that zone. The format for the input is #### in 23 hour format, e.g. 2212. The list of valid military zones is given in http://en.wikipedia.org/wiki/List_of_military_time_zones. Examples of correct output:

  • Given 1230 and zone A, the output would be 1330
  • Given 1230 and zone N, the output would be 1130

Step 1: For each of the functions described above, write down in your notebook the tests that you will perform in order to determine validity.

Step 2: Download the program from $XYZ$.

Step 3: Run the program. You will see a window similar to the following:

Click the 3 Sorts button and you will get the following:

The “Version Alpha” combo box indicates that you are running the first version of the 3 Sorts algorithm. Use the tests that you wrote in step 1 to validate “Version Alpha”. Then, do the same for versions beta, gamma and delta. Report which is the correct version in every method. Also, explain the tests that you performed that allowed you to determine that the other versions are incorrect.

For example, you could organice your results into a table.

| Num | Test | Alpha | Beta | Gamma | Delta | | ------------- | ----------- | ----------- | ----------- | ----------- | ----------- | | 1| “alce”, “coyote”, “zorro” | “alce”, “coyote”, “zorro” | …. | …. | | 2| “alce”, “zorro”, “coyote” | “zorro”, “alce”, “coyote” | …. | …. |

Exercise 2

Running tests “by hand” each time that you run a program gets tiresome very quickly. You and your partner have done it for a few simple functions. Imagine doing the same for full-blown program!, such as a browser or word processor.

Unit tests help programmers produce valid code and ease the process of debugging while avoiding the tedious task of entering tests by hand on each execution.

Step 1: Download the proyect from $XYZ$. The proyect contains only one source code file main.cpp. This file contains four functions whose results are only partially correct. Your task is to write unit tests for each them to identify their wrong results. You do not need to rewrite the functions to correct them.

A unit test function test_fact() is provided for the function fact. If you invoke this function from main and compile and run the program. You will get the following message:

Assertion failed: (fact(2) == 2), function test_fact, file ../UnitTests/main.cpp, line 69.

This would be enough for us to claim that function fact is not correctly implemented. Comment the invocation of test_fact() from main.

Step 2: Write unit tests for the rest of the functions. Remember that you must call each of the unit test functions from the main for them to run. Copy each of the functions in the provided sheet.

References

[1] http://nifty.stanford.edu/2005/TestMe/