La parte Estoy luchando con decir que en todas partes he leído nunca habla de cómo escribir pruebas primero y luego la función. Pero siento que solo funcionará si escribo la función primero y luego escribo pruebas que reflejan el funcionamiento interno de las funciones.
Parece que está sufriendo el problema común de huevos de gallina con test-driven development (TDD). No sabe lo que quiere probar hasta que tenga el código, y cree que no puede hacer TDD a menos que escriba pruebas antes de codificar.
Esto es realmente un caso de Bloque del diseñador (tm). Al igual que el bloqueo del escritor, a menudo es bueno resolverlo mediante la codificación, incluso si arrojas todo ese código.
Hackear un prototipo, y luego pretender que no existe.(no lo envíe :) Este prototipo debe explorar los conceptos con los que no estaba familiarizado, o no tenía suficiente información para comenzar a diseñar. Debería familiarizarte con el problema para que puedas comenzar a diseñar.
Después de que tenga una prueba de concepto, revise el código de la manera más conveniente. En su revisión, determine cómo quiere que sea la interfaz pública, qué patrones arquitectónicos se adaptan mejor al programa y qué dependencias deben aislarse unas de otras (y burlarse de ellas en sus pruebas). Tome notas o presente requisitos en su software de planificación de proyectos/elementos de trabajo en su software de seguimiento de proyectos.
Si tiene problemas para identificar estas cosas en su revisión, debe intentar reclutar a otros programadores (y posiblemente diseñadores/personas que identifiquen los requisitos de su empresa) para que lo ayuden. Un mentor de código puede ser una buena idea.
De esa revisión, usted debería poder comenzar a codificar sus pruebas. O podría comenzar a escribir una especificación técnica: este consejo se aplica igualmente bien a ambos.
(si está trabajando en un equipo, reuniendo los requisitos y obtener retroalimentación de los usuarios/realizar UATs también es necesaria, pero que podría ser el trabajo de otro)
Editar
Tenga en cuenta que este es solo un enfoque para lidiar con este problema. Otra es simplemente relajar cualquier idea puritana sobre cómo debería funcionar TDD, y simplemente desarrollar sus pruebas en paralelo con su código. Verifíquelos al mismo tiempo.
También está perfectamente bien hacer pruebas unitarias sin TDD. Las pruebas unitarias confieren más beneficios que solo codificar su diseño y requisitos. También son una gran ayuda cuando agrega nuevas características o corrige errores (pruebas de regresión) o cuando transporta su código.
Las pruebas de escritura primero es un enfoque adicional llamado TDD: http://stackoverflow.com/questions/tagged/tdd – gideon