Trabajo Practico Obligatorio: Test Driven Development (TDD)

Fecha de entrega: Martes 30 de Junio 2020

Requerimientos

Implementar la funcionalidad de bowling scoring:

The game consists of 10 frames as shown in BowlingGenius. In each frame the player has two opportunities to knock down 10 pins. The score for the frame is the total number of pins knocked down, plus bonuses for strikes and spares.

A spare is when the player knocks down all 10 pins in two tries. The bonus for that frame is the number of pins knocked down by the next roll. So in frame 3 above, the score is 10 (the total number knocked down) plus a bonus of 5 (the number of pins knocked down on the next roll.)

A strike is when the player knocks down all 10 pins on his first try. The bonus for that frame is the value of the next two balls rolled.

In the tenth frame a player who rolls a spare or strike is allowed to roll the extra balls to complete the frame. However no more than three balls can be rolled in tenth frame.

Instrucciones

1. Grupos de hasta 3 integrantes.
2. Crear el repositorio (o bien forkear el presente repo) correspondiente en GitHub y agregar a Martin (mgarriga) como colaborador.
3. Realizar el commit inicial con el test de juego en 0 (en el lenguaje de su elección):

test_gutter_game(game):
  assert game.get_score() == 0

4. Implementar los requerimientos utilizando la metodología TDD.
5. Escribir el readme.MD el cual será el informe del trabajo.

Criterios de evaluación

• El uso de Gitflow o github flow (una version simplificada de GitFlow) es recomendado. La historia de commits nos servirá para evaluar si hicieron el trabajo siguiendo la metodología TDD.

• Hacer branchs por cada feature (aproximadamente una por test case) y hacer commits + Pull Requests que serán cross-checkeados por su compañero. Cada Pull Request comprende los tests además de las funcionalidad.

• Se recomienda, aunque no es obligatorio, usar pair programming (2 programadores con una pc). En ese caso, deben alternar ambos cada rol (piloto/copiloto) y commitear con sus respectivos usuarios a los fines evaluativos.

• Pueden utilizar el lenguaje que prefieran.

  • Si usan javascript recomendamos mocha como herramienta de testing y nyc/istambul para analizar el coverage de los tests.
  • Si usan python recomendamos [pytest] (https://docs.pytest.org/en/latest/) para los tests y Coverage.py para analizar el % de coverage de los tests.
  • Si usan Java recomendamos JUnit para los tests y algun plugin de Eclipse/IntelliJ/VScode para el coverage.

• El informe del proyecto será el Readme.MD del repositorio, el cual debe contener:

  • Instrucciones para correr el proyecto.
  • Ejemplo de un ciclo de TDD (Red/Green/Refactor) para alguna de las funciones implementadas.
  • Tipos de Test aplicados y ejemplos (remitirse a la teoría de la materia).
  • Conclusiones: Dificultades y ventajas percibidas en cuanto a la metodología TDD y al proyecto en sí, críticas constructivas

• La finalidad del trabajo no es sólo la aprobación de la materia sino que utilicen metodologías y herramientas actuales (TDD, Github flow, etc.) y puedan aprender y resolver problemas de manera autónoma.