====== Cómo correr los tests del proyecto 2 ======

Confirmar que tienen instalados las siguientes dependencias:

  * python2.7
  * python-virtualenv
  * git-core
  * valgrind
  * indent

Para ello, en una terminal, correr los comandos:

  $ sudo apt-get update

  $ sudo apt-get install python2.7 python-virtualenv git-core valgrind indent

===== 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 ú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_VERSION_FECHA.tar.gz
  $ 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):

  $ gcc -Wall -Werror -Wextra -pedantic -std=c99 -fPIC -g -c index.c data.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

Correr los tests usando python:

  $ python2.7 -m unittest discover -v tests/

Lo de arriba tienen que haber andado bien (debería mostrar OK), correr ahora los mismos tests pero con valgrind:

  $ 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. Esto lo hacen buscando por los strings:

  * dict.c
  * list.c
  * pair.c
  * index.c
  * data.c

===== 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

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
  
Ahora también deben correr los tests de estilo de código:

  $ python2.7 -m unittest discover -v style_tests/

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 =====

Por último, correr los tests de aceptación. Para ello hay que crear un entorno virtual para Python, activarlo con los siguientes comandos:

  $ virtualenv -p /usr/bin/python2.7 ~/facu-ayed2-env
  $ source ~/facu-ayed2-env/bin/activate

Una vez dentro del entorno virtual (se diferencia porque el prompt cambia), instalar esta nueva dependencia:

  (facu-ayed2-env)$ pip install -e git+https://github.com/matiasb/pexpect-fixtures@2ae01968b50224f180d867574c69ed9d88539131#egg=pexpect_fixtures

Luego, compilar el diccionario como siempre, y correr:

  $ ./run_acceptance.sh dictionary ./tests/fixtures/

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/