Diferencias

Muestra las diferencias entre dos versiones de la página.

--- algo2:main:run-tests-proy2-a [2014/04/07 02:04] – nbidart
+++ algo2:main:run-tests-proy2-a [2018/08/10 03:03] (actual) – editor externo 127.0.0.1
@@ Línea 1: / Línea 1: @@
-====== Cómo correr los tests del proyecto 2, parte A ======
+====== Cómo correr los tests del proyecto 2 ======
 Confirmar que tienen instalados las siguientes dependencias:
@@ Línea 15: / Línea 15: @@
   $ sudo apt-get install python2.7 python-virtualenv git-core valgrind indent
-===== Correr los tests de unidad con el esqueleto de la cátedra =====
+===== Correr los tests de unidad con los .o de la cátedra =====
 Primero que nada, probar con el esqueleto de código dado por la cátedra. Como ejemplo, vamos a usar el de 64bits. Todas las líneas de esta documentación que empiezan con el símbolo peso, indican que el comando debe ser corrido en una terminal.
-Bajar el esqueleto eligiendo la arquitectura que necesitan y guardarlo en el disco. Luego, lo descomprimen y entran en ese directorio:
+Bajar el último esqueleto eligiendo la arquitectura que necesitan y guardarlo en el disco. Luego, lo descomprimen y entran en ese directorio:
-  $ tar xzvf dictionary-skeleton-amd64_1.1_2014-04-06.tar.gz
+  $ tar xzvf dictionary-skeleton-amd64_VERSION_FECHA.tar.gz
-  $ cd dictionary-skeleton-amd64_1.1_2014-04-06
+  $ cd dictionary-skeleton-amd64_VERSION_FECHA
 Ahora, compilar las librerías del dict y de la lista (respetar al pie de la letra los comandos):
@@ Línea 38: / Línea 38: @@
   $ valgrind --leak-check=full --show-reachable=yes --log-file=valgring.log python2.7 -m unittest discover -v tests/
-Ahora tienen un archivo nuevo valgrind.log con mucho output, deberían buscar accessos inválidos a memoria, invalid free o memory leaks relacionados con sus archivos.
+Ahora tienen un archivo nuevo valgrind.log con mucho output, deberían buscar accessos inválidos a memoria, invalid free o memory leaks relacionados con sus archivos. Esto lo hacen buscando por los strings:
-===== Correr los tests de unidad con el dict.c propio =====
+  * dict.c
+  * list.c
+  * pair.c
+  * index.c
+  * data.c
-Ahora, para probar el codigo de Uds, deberían borrar el dict.o y el main.o:
+===== Correr los tests de unidad con el dict.c/list.c/pair.c propio =====
+Ahora, para probar el codigo de Uds, deberían borrar todos los .o de la cátedra que quieren reemplazar por el propio:
   $ rm dict.so dict.o main.o
-Y repetir los pasos de arriba pero compilando los .c de Uds:
-  $ gcc -Wall -Werror -Wextra -pedantic -std=c99 -fPIC -c dict.c
+Si van a correr los tests de la lista, borrar:
+    $ rm list.so list.o pair.o
+Y repetir los pasos de la sección de arriba pero compilando los .c de Uds:
+  $ gcc -Wall -Werror -Wextra -pedantic -std=c99 -fPIC -c dict.c pair.c list.c
+  $ gcc -shared -o list.so index.o data.o pair.o list.o
   $ gcc -shared -o dict.so index.o data.o pair.o list.o dict.o
@@ Línea 56: / Línea 67: @@
 Y correr los tests de unidad, con el comando que usa valgrind, hasta que no tengan errores ni problemas de memoria en el código de Uds.
+  $ valgrind --leak-check=full --show-reachable=yes --log-file=valgring.log python2.7 -m unittest discover -v tests/
+===== Correr un sub-set de tests de unidad =====
+Para correr los tests sólo del pair, o sólo los de la lista, sacar la parte del comando que dice "discover" y poner en vez algo de esta pinta:
+  $ python2.7 -m unittest -v tests.test_pair
+O por ejemplo:
+  $ python2.7 -m unittest -v tests.test_list
+No se olviden de siempre usar valgrind junto con el comando que corre los tests.
 ===== Correr los tests de aceptación =====
@@ Línea 73: / Línea 98: @@
 Todo el output de la corrida de acceptance va a estar en el archivo acceptance-valgrind.log.
+===== NUEVO: Correr los tests del BST =====
+Primero que nada, bajar los archivos de tests para el BST, desde acá:
+{{:algo2:main:2014:bst-test-files-2014-05-03.tar.gz|bst-test-files-2014-05-03.tar.gz}}
+Luego, copiar los archivos en los lugares adecuados según se explica a continuación:
+  * bst_wrapper.py -> archivo auxiliar que necesitan los tests, tiene que ir dentro de la carpeta tests/
+  * test_bst.py -> los tests de unidad del BST como TAD "aislado" (sin interacción con el dict ni ningún otro TAD), tiene que ir dentro de la carpeta tests/
+  * from-to-file.fx -> fixture con tests de load/dump del dict a archivos, que hay que cambiarlo porque ahora el dict usa el BST, el dict queda guardado "distinto" en disco, tiene que sobreescribir el archivo de mismo nombre es tests/fixtures/
+Luego, necesitan compilar la librería del BST (bst.so) para que los tests de unidad del BST funcionen. Esto es, generar el bst.so, tal como antes generaban el list.so y dict.so:
+  $ gcc -Wall -Werror -Wextra -pedantic -std=c99 -g -fPIC -c index.c data.c pair.c list.c bst.c dict.c
+Como antes, generan el list.so:
+  $ gcc -shared -o list.so index.o data.o pair.o list.o
+Ahora, generan la librería nueva, bst.so:
+  $ gcc -shared -o bst.so index.o data.o pair.o list.o bst.o
+También tienen que regenerar el dict.so que ahora depende del bst:
+  $ gcc -shared -o dict.so index.o data.o pair.o list.o bst.o dict.o
+Luego, como antes, los tests se pueden correr de "a pedazos". Para correr los del bst solamente:
+  $ python -m unittest --verbose tests.test_bst
+Para correr los del dict solamente (require el dict.so contruido con el bst.c, como dice arriba):
+  $ python -m unittest --verbose tests.test_dict
+Por último, para correr todos los tests de unidad, pueden usar:
+  $ python -m unittest discover --verbose tests/
+==== Correr los tests de estilo de código ====
+Del tarball arriba nombrado, copiar el siguiente archivo:
+  * test_bst_code_style.py -> los tests de estilo para el bst.c y bst.h, este archivo tiene que ir dentro de la carpeta style_tests/
+Para correr los tests de estilo del árbol solamente:
+  $ python -m unittest --verbose style_tests.test_bst_code_style
+Para correr todos los tests de estilo:
+  $ python -m unittest discover --verbose style_tests/