A revisão do código deve ser realizada antes ou depois dos testes de unidade

Estou debatendo com meu colega sobre quando executar a revisão de código - antes ou depois dos testes de unidade. Qual é a melhor prática?

Alguns fatores que precisamos levar em consideração (pode haver mais):

• Tamanho da alteração do código - uma grande alteração significa que mais alterações resultarão da revisão do código. Se essas alterações forem grandes, se a UT foi anterior à revisão do código, você precisará repetir a maioria das UTs novamente.
• Tempo necessário para realizar o teste de unidade
• É uma nova funcionalidade ou uma correção de bug

Você deve sempre testar a unidade antes de fazer a revisão do código e aqui está o porquê

1. Se seu código for quebrado de uma maneira que seria detectada pelos testes de unidade, você estará perdendo o tempo do outro desenvolvedor, envolvendo-os no ciclo de vermelho / verde / refatorador.
2. Os testes mostram a outros desenvolvedores o uso pretendido do código, o que facilita a revisão.
3. Os testes devem ser revisados ​​junto com o código testado, caso você esteja faltando casos de teste ou seus testes não funcionem corretamente.
4. Testes e revisão de código tendem a detectar problemas diferentes, com apenas uma pequena sobreposição nos problemas encontrados. Os testes de unidade não ficam aborrecidos por ter que testar novamente o código quando o revisor encontra problemas, os desenvolvedores ficam aborrecidos e provavelmente não farão tão bem na segunda vez.

Provavelmente, existem outros motivos, mas esses são os que eu pessoalmente vi e experimentei ao implementar práticas de revisão de código em três equipes / empresas diferentes.

Editar Claro que o acima é para momentos em que a revisão do código é um passo em seu processo de desenvolvimento de software (se cachoeira ou ágil). Se você estiver trabalhando em uma seção de código particularmente grande ou difícil, sinta-se à vontade para encontrar outro par de olhos a qualquer momento.

As revisões de código são para quando o código é "concluído".

Na minha organização, nossa definição de "concluído" inclui testes de unidade (como pretendemos para o TDD), portanto as revisões de código são de código completo - e o código completo inclui testes.

Além disso, os testes precisam ser revisados ​​e refatorados, para que faça sentido que eles façam parte da revisão do código.

Os testes devem ser considerados parte do código a ser revisado. Portanto, faz sentido revisar após a conclusão dos testes.

Certifique-se de que os testes também sejam revisados. Isso é crítico para quem é novo nos testes de unidade.

Verifique se sua equipe entende a injeção de dependência, estruturas de isolamento, zombarias versus stubs, costuras, testes baseados em interação versus estado e integração versus testes de unidade.

Você não precisa implementar os tópicos mencionados acima, mas deve entendê-los.

Bem,

Isso depende do que você quer dizer com "Teste de Unidade" ...

Se foi um teste de unidade no estilo TDD, não faz sentido porque você escreve teste enquanto escreve seu código. Não há nenhum caso posterior.Neste caso, você melhora a qualidade do código continuamente: Refatorando ...

E

Se era um "teste de unidade" clássico [o que quer dizer que eu não sei, mas eu quero dizer teste depois de escrever os códigos e geralmente feito por outros caras], o principal critério é o que você espera da revisão de códigos e da natureza dos testes de unidade: se você deseja uma revisão rápida - faça uma revisão e tome medidas e não tenha um teste de unidade automatizado, terá que aguardar o teste de unidade. Se você deseja identificar problemas antigos com a revisão de código e aplicar gradualmente a solução para as próximas iterações, poderá fazê-lo antes do teste de unidade ...

Mas, afinal, pessoalmente, para a revisão por código, o teste de unidade após ou mais tarde não é um critério real para mim ...

Por que fazemos revisão de código? Para a qualidade do código ... Em vez de uma porta de "controle de qualidade", injete qualidade no ambiente do processo de desenvolvimento de software ...

Eu diria que vamos ser "ágeis" ... não espere o código terminar para fazer uma revisão rápida e informal do código: existem desenvolvedores com quem e assuntos com os quais você pode realmente esperar o tempo todo código + fase de teste a ser concluída ... mas

quando se trata de assuntos realmente novos (recurso totalmente novo, quase pesquisa, algo totalmente novo para a equipe), revisão de código mais cedo, não perca tempo: faça com que um colega de trabalho veja de vez em quando: o isolamento é um fator importante de falha neste caso.

se o desenvolvedor também é novo na equipe, revise o código cedo e talvez com frequência .

e, a propósito, os testes de unidade também precisam de revisão de código.