curriculum
curriculum copied to clipboard
Laboratoria
Observaciones Text Analyzer DEV012
- En los test no se especifica que deben tener un data set para correr los test de oas de html.
- Las pruebas e2e están sujetas a una versión específica de node, causando que estudiantes con un S.O con node inferior al soportado (+v14) no puedan ejecutarlo.
- La sección de "Criterios de aceptación mínimos del proyecto" actualmente carece de información detallada en el subpunto de “Funciones”. Es esencial proporcionar criterios específicos que se alineen con los objetivos de aprendizaje para que las estudiantes puedan asegurarse de que sus implementaciones cumplen con las expectativas del proyecto (el readme no precisa las condicionales que deben ser considerados en los métodos para lograr pasar las pruebas exitosamente, lo cual luego genera que se deba modificar la lógica). Se debería detallas aún más esta sección para incluir detalles como los casos de uso esperados.
- Proporcionar instrucciones detalladas para la ejecución y comprensión de las pruebas (finalidad de cada una de ellas, sobre todo las e2e).
- Detalles sobre la implementación de funcionalidades opcionales y ajustes en las pruebas, más detalle sobre cómo se deben implementar estas funcionalidades y cómo se pueden habilitar y ajustar las pruebas unitarias y de e2e asociadas (se podría incluir un ejemplo).
- En los test no se especifica que deben tener un data set para correr los test de oas de html.
Podemos resaltar eso en el README
- Las pruebas e2e están sujetas a una versión específica de node, causando que estudiantes con un S.O con node inferior al soportado (+v14) no puedan ejecutarlo.
Vamos considerar eso en otro Issue #1647
- La sección de "Criterios de aceptación mínimos del proyecto" actualmente carece de información detallada en el subpunto de “Funciones”. Es esencial proporcionar criterios específicos que se alineen con los objetivos de aprendizaje para que las estudiantes puedan asegurarse de que sus implementaciones cumplen con las expectativas del proyecto (el readme no precisa las condicionales que deben ser considerados en los métodos para lograr pasar las pruebas exitosamente, lo cual luego genera que se deba modificar la lógica). Se debería detallas aún más esta sección para incluir detalles como los casos de uso esperados.
Hm no se donde empezamos con este feedback. Es algo que necesitamos comunicar mejor en el readme o en los Q+As?Quiza @ssinuco puede responder y tener una idea de que hacemos
- Proporcionar instrucciones detalladas para la ejecución y comprensión de las pruebas (finalidad de cada una de ellas, sobre todo las e2e).
Hay eso que me parece bien. No se si @ssinuco tiene mas ideas sobre eso.
- Detalles sobre la implementación de funcionalidades opcionales y ajustes en las pruebas, más detalle sobre cómo se deben implementar estas funcionalidades y cómo se pueden habilitar y ajustar las pruebas unitarias y de e2e asociadas (se podría incluir un ejemplo).
Por ahora no creo es mucha prioridad porque son opcionales. Que piensas @ssinuco ?
- La sección de "Criterios de aceptación mínimos del proyecto" actualmente carece de información detallada en el subpunto de “Funciones”. Es esencial proporcionar criterios específicos que se alineen con los objetivos de aprendizaje para que las estudiantes puedan asegurarse de que sus implementaciones cumplen con las expectativas del proyecto (el readme no precisa las condicionales que deben ser considerados en los métodos para lograr pasar las pruebas exitosamente, lo cual luego genera que se deba modificar la lógica). Se debería detallas aún más esta sección para incluir detalles como los casos de uso esperados.
Hm no se donde empezamos con este feedback. Es algo que necesitamos comunicar mejor en el readme o en los Q+As?Quiza @ssinuco puede responder y tener una idea de que hacemos
No estoy de acuerdo con entregar mas detalles en cómo implementar las funciones. En desarrollo de software no hay soluciones únicas y esto hace parte de los aprendizajes que debe tener una estudiante. Por otro lado es imposible escribir una prueba de análisis estático de código que valide si un condicional se escribió como se especificó.
- Proporcionar instrucciones detalladas para la ejecución y comprensión de las pruebas (finalidad de cada una de ellas, sobre todo las e2e).
Hay eso que me parece bien. No se si @ssinuco tiene mas ideas sobre eso.
Me parece que lo esta es suficiente. Tiene un texto que explica de que se trata la prueba y un gif que explica como ejecutarla. No veo como podemos explicar con mas claridad.
- Detalles sobre la implementación de funcionalidades opcionales y ajustes en las pruebas, más detalle sobre cómo se deben implementar estas funcionalidades y cómo se pueden habilitar y ajustar las pruebas unitarias y de e2e asociadas (se podría incluir un ejemplo).
Por ahora no creo es mucha prioridad porque son opcionales. Que piensas @ssinuco ?
De nuevo, no soy partidario de entregar detalles de implementacion, pues hace parte del trabajo de las estudiantes descubrir como y de las coaches guiarlas en el proceso. No sobrecargaria el README mas.