Es una pregunta interesante y la respuesta podría ser más fácil de lo que piensas.
En pocas palabras, escriba pruebas que validen sus suposiciones. No importa si hace la implementación o sus compañeros programadores
La respuesta larga.
Cualquiera de las opciones que enumeras son un tanto pasivas y requieren que tú regrese y vuelva a visitar el código (si existe) tarde o temprano.
-
Comentarios deben ser leídos y manejados por su contraparte responsable de la implementación. Tu código no puede ser compilado mientras tanto. Si verifica dicho estado en un repositorio de código, su canalización de integración continua no funcionará, y es una mala práctica de todos modos ... nunca verifique el código roto
-
Las excepciones de tiempo de ejecución parecen mejores, pero siguen siendo tóxicas, porque su compañero programador podría asumir que la implementación ya se realizó sin verificar, dejando al sistema también en un estado inestable. Si el método se activa con poca frecuencia, podría dar lugar a un código de producción dañado ... también es una mala práctica ... nunca verifique las excepciones "no implementadas"
-
Esperar a que sus compañeros programadores para la implementación de los métodos o un código auxiliar también es desalentador. Rompe su flujo de trabajo y el flujo de trabajo de sus compañeros programadores. ¿Qué sucede si están enfermos, en una reunión a, en un descanso para tomar un café, desea pasar el tiempo esperando? ... no esperes a alguien si no tienes que hacerlo
-
implemente los métodos que faltan definitivamente la mejor manera de avanzar. ¿Pero qué sucede si su implementación no satisface todo el caso de uso y sus compañeros programadores necesitan enmendarlo o cambiarlo? ¿Cómo se aseguran usted y ellos de que sigue siendo compatible con su intención? La respuesta es fácil de nuevo. Escribe pruebas que verifiquen, describan y documenten tus intenciones. Si las pruebas se rompen, es fácil darse cuenta. Si es necesario hacer cambios en ese método que rompan tu función ... lo ves inmediatamente. Ambos tienen una razón para comunicarse y decidir qué hacer. ¿Dividir la funcionalidad? Cambie su implementación, etc. nunca ingrese el código que no esté suficientemente documentado por las pruebas
Para lograr un nivel de prueba suficiente, sugeriría que analice dos disciplinas.
-
TDD: desarrollo guiado por pruebas: esto le asegurará que describa su intención y la pruebe lo suficiente. También le da la posibilidad de simular o falsificar métodos y clases (también mediante el uso de interfaces) que aún no están implementados. El código y las pruebas aún se compilarán y le permitirán probar su propio código de forma aislada del código de sus compañeros programadores. (vea: enlace )
-
ATDD: desarrollo basado en pruebas de aceptación: esto creará un bucle externo (alrededor del bucle TDD) que le ayuda a probar la característica en su totalidad. Estas pruebas solo se volverán verdes cuando se implemente toda la función, lo que le dará un indicador automático cuando sus compañeros completen su trabajo. Bastante limpio si me preguntas.
Advertencia: en su caso, solo escribiría pruebas de aceptación simples y no trataré de incluir demasiado del lado comercial, ya que sería demasiado para empezar. Escriba pruebas de integración simples que reúnan todas las partes del sistema que requiere la función. Eso es todo lo que se requiere
Esto le permitirá poner su código en una tubería de integración continua y producir una implementación altamente confiable.
Si desea obtener más información sobre este tema, consulte los siguientes enlaces: