Part one

[rsaladocid]

Os cuento un poquito lo que hemos hecho para cuando lo reviséis:

• Hemos reorganizado el directorio de apps según lo que hablamos (usando
  la misma estructura que usa Codely en sus otros repos de DDD)

• Ya implementamos el controlador para el health check junto con el test
  de aceptación. Sobre esto un par de cositas:

  • El nombre del controlador es "Status" porque es el nombre que
    ellos le dan. En general, estamos respetando el "naming" que ellos usan.

  • Codely usa Behat para definir los tests de aceptación, que
    permite definir tests a un nivel mayor nivel de abstracción que si
    usaramos supertest directamente. En Javascript tenemos Cucumber, que al
    igual que Behat, usa Gherkin para definir los escenarios. Esto hace que
    la definición de los escenarios que ellos han definido sean compatibles
    en nuestro caso. Creemos que así se acerca más a lo que Codely espera.
    De todas formas, podemos debatir sobre esto si lo veis oportuno.

• Ya está el caso de uso de crear un curso, con sus tests
  correspondientes, tal y como lo hacen ellos en el bloque 1 del curso de
  PHP-DDD. Digo esto porque ellos, según va avanzando el curso, van
  refactorizando sobre lo que se va haciendo, por ejemplo, incluyendo
  value objects. Entendemos que quieren seguir esa misma forma de
  trabajar, por lo que lo hemos respetado y lo hemos implementado de la
  forma más parecida posible a como ellos lo hacen.

Cualquier cosa que haya que comentar, estamos por aquí.

Saludos!!!!

[vilasmaciel]

👏👏

• Sobre la estructura del directorio apps, veo que en el de php existe la siguiente:

| applications \
| - mooc_backend \
| -- bin 
| -- config 
| -- src
| -- web

Nosotros aquí nos estamos saltando la carpeta src que va dentro de mooc_backend, yo lo veo bien por qué por características del stack nos compensa tener una carpeta src en el raiz del proyecto. Simplemente lo apunto para que @JavierCane @rgomezcasas lo tengan en cuenta.

• Sobre lo de cucumber, 100% de acuerdo. Creo que ya estaba en el plan meterlo, la solución que habéis implementado está genial, utilizar supertest en los steps creo que es una buena opción ya que es una herramienta muy cómoda para este tipo de pruebas. He añadido la ejecución de los tests de cucumber al comando npm test para que se pase toda la testsuite en cada ejecución (está configuradas las github actions y se ejecutan todos los tests en cada cada PR)