É uma pergunta interessante e a resposta pode ser mais fácil do que você pensa.
Simplificando, escreva testes que validem suas suposições. Não importa se você faz a implementação ou seus colegas programadores
A resposta longa.
Qualquer uma das opções listadas é um pouco passiva e requer que você retorne e revisite o código (se houver) mais cedo ou mais tarde.
- Os Comentários precisam ser lidos e manipulados por sua contraparte responsável pela implementação. Seu código não pode ser compilado nesse meio tempo. Se você verificar esse estado em um repositório de código, seu pipeline de integração contínua não funcionará, e é uma prática ruim de qualquer maneira ... nunca verifique o código quebrado
- Exceções em tempo de execução parecem melhores, mas ainda são tóxicas, porque o seu colega programador poderia assumir que a implementação já foi feita sem verificação, deixando o sistema em um estado instável também. Se o método não for acionado com tanta frequência, pode levar a um código de produção desfeito ... prática ruim também ... nunca verifique exceções "não implementadas"
- Esperando por seus colegas programadores para implementação dos métodos ou um stub também é assustador. Isso quebra seu fluxo de trabalho e o fluxo de trabalho de seus colegas programadores. O que acontece se eles estão doentes, em uma reunião, no intervalo do café, você quer gastar seu tempo esperando? ... não espere por alguém se você não tiver que
- implementa os métodos que faltam definitivamente é a melhor maneira de avançar. Mas o que acontece se a sua implementação não satisfizer todo o caso de uso e seus colegas programadores precisarem alterar ou alterar isso? Como você e eles se certificam de que ainda é compatível com o que você pretende? A resposta é fácil novamente. Escreva testes que verifiquem, descrevam e documentem suas intenções. Se os testes quebrarem, é fácil notar. Se mudanças nesse método precisarem ser feitas para quebrar seu recurso ... você o verá imediatamente. Vocês dois têm um motivo para se comunicar e decidir o que fazer. Dividir a funcionalidade? Altere sua implementação, etc ... nunca verifique o código que não está suficientemente documentado por testes
Para alcançar um nível suficiente de testes, sugiro que você dê uma olhada em duas disciplinas.
-
TDD - desenvolvimento orientado a testes - isso fará com que você descreva sua intenção e a teste suficientemente. Também oferece a possibilidade de simular ou falsificar métodos e classes (também usando interfaces) que ainda não foram implementadas. O código e os testes ainda irão compilar e permitir que você teste seu próprio código isoladamente do código de seus colegas programadores. (veja: link )
-
ATDD - desenvolvimento orientado a testes de aceitação - isso criará um loop externo (em torno do loop TDD) que ajudará você a testar o recurso como um todo. Esses testes só ficarão verdes quando todo o recurso for implementado, dando a você um indicador automático quando seus companheiros concluírem seu trabalho. Bastante arrumado, se você me perguntar.
Advertência: No seu caso, eu só escreveria testes de aceitação simples e não tentaria trazer muito do lado do negócio, já que seria muito para começar. Escreva testes de integração simples que reúnam todas as partes do sistema que o recurso requer. Isso é tudo o que é necessário
Isso permitirá que você coloque seu código em um pipeline de Integração Contínua e produza uma implementação altamente confiável.
Se você quiser ir mais longe nesse tópico, verifique os seguintes links: