método de evaluación de tareas para las escuelas: ¿cómo fomentar las buenas prácticas y el diseño y reducir la dependencia de la corrección de pruebas?

Está solicitando una canalización de revisión de código completamente automatizada, también conocida como el Santo Grial.

Por partes:

• Lógica defectuosa: en teoría, esto puede detectarse mediante pruebas. Pero si fuera tan fácil, el software estaría libre de errores. Si la tarea es lo suficientemente simple como para que haya una sola forma de hacerlo, puede predecir los algoritmos y diseñar casos de esquina para probar. Si hay más de una forma (y las personas, especialmente los principiantes, encontrarán otra forma, por complicada que sea), tendría que revisarlas, ver qué algoritmos están usando y ser cruel con ellas.
• Estilo de código: hay herramientas automatizadas para comprobar el estilo y las buenas prácticas, como cppcheck , pero son bastante tontas. Algunas configuraciones son demasiado entusiastas y son completamente incapaces de ver a través de la estructura general, encontrar funciones demasiado largas o hacer cumplir una responsabilidad única. Además, están diseñados para dar sugerencias al programador, que evaluará si corresponde ("¿realmente necesito documentar esta función auxiliar de 3 líneas con un nombre y una firma perfectamente claros?").

Entonces, en general, no, eso no es posible. La única manera que se me ocurre es facilitar la expansión de su marco de prueba y evaluación. Cuando el TA encuentra un error en un programa, se le agrega un test, y todos pasan por el pipeline, y eso se convierte en una cosa menos que revisar.

Para hacer cumplir las buenas prácticas, lo mejor que se me ocurre es hacer que la aplicación crezca tarea tras tarea. Si está mal codificado, expandirlo y mantenerlo será un gran esfuerzo, y el beneficio de las buenas prácticas se hará evidente. Construir bases de código más grandes es, en mi opinión, la única forma en que uno puede realmente entender y creer por qué los patrones y las convenciones son útiles y no solo el producto de algunos tipos exigentes con TOC.

Pero puedes hacer trampa. Por ejemplo, puede verificar minuciosamente manualmente las presentaciones con la puntuación de estilo más baja que pasan todas las pruebas (suponiendo que sean las que están peor codificadas), y encontrar los casos de esquina donde fallarían y agregarlos a su batería de pruebas. Sin embargo, esto es injusto, ya que está dirigiendo su castigo a envíos específicos.