¡Esta es una revisión vieja del documento!
Tabla de Contenidos
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.