Sig: Repaso: Pruebas en el Sup: Haciendo mas Modular el Ant: Práctica: Pruebas en el Err: Si hallas una errata ...

Práctica: Mas Pruebas y Extensiones al Análizador Léxico

Extienda la práctica con las siguientes características:

1. Cuando la entrada al compilador tiene blancos al final:

   PL-Tutu/scripts$ cat test02.tutu
   int a,b;
   a = 4
   

   El analizador léxico produce una salida errónea:

   PL-Tutu/scripts$ tutu test02.tutu test01.sal
   Error: Caracter invalido:
   
    at ../lib/PL/Lexical/Analysis.pm line 19
   

   Corriga el fallo y convierta el fallo en una prueba.
2. Mejore la práctica anterior para que distinga entre el terminal NUMINT y el terminal NUMFLOAT. Observe que la expresión regular del segundo contiene a la del primero. Por supuesto es un caso TIMTOWTDI. Por ejemplo, una manera es: una vez capturado un NUMFLOAT podemos saber si se trata de un NUMINT atendiendo al índice del último paréntesis que casó (véase sección 4.3 ).
3. Modularize las diferentes fases del compilador (tal y como se explicaron en la sección 11.2) e introduzca pruebas TODO usando can_ok para las funciones que están por escribir (parser, Optimize, code_generator, transform). Repáse la sección 6.16.7.
4. Una prueba SKIP declara un bloque de pruebas que - bajo ciertas circustancias - puede saltarse. Puede ser que sepamos que ciertas pruebas sólo funcionan en ciertos sistemas operativos o que la prueba requiera que ciertos paquetes están instalados o que la máquina disponga de ciertos recursos (por ejemplo, acceso a internet). En tal caso queremos que los tests se consideren si se dan las circustancias favorables pero que en otro caso se descarten sin protestas. Consulte la documentación de los módulos Test::More y Test::Harness sobre pruebas tipo SKIP. El ejemplo que sigue declara un bloque de pruebas que pueden saltarse. La llamada a skip indica cuantos tests hay, bajo que condición saltarselos.

    1  SKIP: {
    2      eval { require HTML::Lint };
    3 
    4      skip "HTML::Lint not installed", 2 if $@;
    5 
    6      my $lint = new HTML::Lint;
    7      isa_ok( $lint, "HTML::Lint" );
    8 
    9      $lint->parse( $html );
   10      is( $lint->errors, 0, "No errors found in HTML" );
   11  }
   

   Si el usuario no dispone del módulo HTML::Lint el bloque no será ejecutado. El módulo Test::More producirá oks que serán interpretados por Test::Harness como tests skipped pero ok.

   Introduzca una prueba SKIP: Si existen ficheros skip.tutu y skip.sal en el directorio t realize una prueba que compile skip.tutu y compruebe que la salida coincide con la de skip.sal. Si los ficheros no existen la prueba no se ejecuta.

   Lea perldoc Test::Tutorial para estudiar el tutorial de Michael Schwern sobre pruebas.

5. Use el módulo Test::Pod para introducir un test que compruebe que la documentación esta bien escrita. Estudie la documentación del módulo Test::Pod.
6. Para mejorar la calidad de los mensajes de error extienda el par (terminal, valor) devuelto por el scanner a una terna (terminal, valor, número de línea) cuya tercera componente es el número de línea en el que aparece el terminal.

   Hay muchas formas de hacerlo. Una posibilidad es apoyarse en el operador tr (descrito en la sección 4.27) el cuál ademas de reemplazar devuelve el número de carácteres reeemplazados o suprimidos:

   $cuenta = $texto =~ tr/\n/\n/; # cuenta los retornos de carro en texto
   

   Modifique las pruebas para que se adapten a la nueva interfaz de scanner.

Sig: Repaso: Pruebas en el Sup: Haciendo mas Modular el Ant: Práctica: Pruebas en el Err: Si hallas una errata ...