Práctica: HTML DSL con Git y Rake

Complete la práctica descrita en la sección 15.15 con los siguientes requisitos:

• Use git y github para el desarrollo de la práctica. Cree en el repositorio un subproyecto LPP y en el mismo un subproyecto para la práctica.
• Documente el código
• En el directorio lib residirá la librería
• Cree un directorio test en el que residirán las pruebas
• Escriba las pruebas. Recuerde:
  • Todas las pruebas deben automatizarse
  • Todos los fallos que se detecten deberían quedar traducidos en pruebas
  • La aplicación debería pasar todas las pruebas después de cualquier modificación importante y también al final del día
  • El desarrollo de las pruebas debería preceder el desarrollo del código
  • Todos los requerimientos deben ser expresados en forma de pruebas
  • El tiempo invertido en Comprobar (testing) y el tiempo invertido en Depurar (debugging) mantiene una relación inversa. Cuanto menor es el tiempo invertido en la preparación de pruebas mayor será nuestro tiempo de depuración. Cuanto mejor sea nuestra suite de pruebas menor será el tiempo que necesitemos para fijar errores en nuestros programas.
  • Las pruebas no aseguran la corrección de nuestro programa. Las pruebas descubren errores. Una prueba tiene éxito cuando falla y demuestra la presencia de un error.
  • En palabras de Bruce Eckel (Thinking in Java):

    You can write all the prose, or create all the diagrams you want, describing how a class should behave and what it looks like, but nothing is as real as a set of tests. The former is a wish list, but the tests are a contract that is enforced by the compiler and the running program. It's hard to imagine a more concrete description of a class than the tests

  • Cuando escriba las pruebas invierta su escala de valores: Alégrese cuando una prueba descubre un error. Es peor que el error esté ahí y no sea descubierto.
  • Que comprobar:
    • Convertir cualquier fallo que encontremos en una prueba
    • Comprobar el funcionamiento en mas de una plataforma
    • Dar valores de entrada erróneos o en el límite. Por ejemplo:
      • Los valores máximo y mínimo posibles
      • Cadenas vacías
      • Cadenas multilínea
      • Entradas con caracteres de control, etc.
      • Valores como '0', '0E0', listas vacías, hashes vacíos, etc.
      • Llamar sin argumentos a una rutina que los espera y viceversa
      • Llamar a una rutina con mas argumentos de los que espera
      • Llamar a una rutina con los argumentos en orden incorrecto
    • Estudie las interacciones y dependencias entre recursos que se da por sentado que están (pero que a veces pueden no estar. Por ejemplo, un fichero con cuya existencia se cuenta)
    • Estudie la dependencia de versiones del software instalado
    • Compruebe que toda subrutina se prueba al menos una vez. Prepare para cada subrutina importante al menos una prueba que cubra el caso promedio y otra que compruebe su funcionamiento en casos límite.
    • Estudie la escalabilidad de la distribución con valores tendiendo al límite. Ficheros grandes, números grandes, etc.

• Cree un Rakefile con diferentes objetivos:
  • test para ejecutar las pruebas
  • dist para crear un tar.gz con todos los ficheros
  • zip para crear un zip con todos los ficheros
  • clean para borrar ficheros temporales