¿Las personas escriben pruebas unitarias durante un Hackathon?

Si son inteligentes, escribirán solo las pruebas unitarias que les permitan realizar la tarea más rápido.

(Por supuesto, nadie es realmente TAN inteligente, pero puedes intentarlo).

Las pruebas unitarias no son todas de igual valor. Algunos lo ayudan a comprender mejor el problema. Algunos evitan que pierdas el tiempo depurando algo que rompes repetidamente. Algunos evitan que pierdas el tiempo buscando un error en el lugar equivocado (es decir, si la prueba funciona, sabes que el error no está allí).

Algunas pruebas unitarias tardan mucho tiempo en escribirse. Algunos nunca se van. Los mal escritos o mal diseñados tienen que actualizarse repetidamente a medida que evoluciona su código. Algunos tardan tanto en correr que ralentizan su ciclo.

Mucha experiencia con las pruebas unitarias lo ayuda a tomar mejores decisiones sobre cuándo usarlas y qué deben probar. Lo mismo ocurre con la estrategia de estar dispuesto a reducir sus pérdidas: ¡abandone una prueba que está causando problemas o agregue una prueba cuando vea que no le está causando problemas!

No es tan diferente del desarrollo regular, en general. Las diferencias están en los incentivos y las compensaciones, no en los principios.

Nunca he escrito pruebas en un hackathon. Para ser sincero, apenas termina su producto a tiempo en primer lugar. Además, en un hackathon, la aplicación final es muy hacky, y los desarrolladores a menudo codifican muchos valores para llevar la idea a casa.

Nadie tiene tiempo para eso (en un hackathon)