Escolhendo nomes para testes de integração

Com os testes de unidade, o domínio é muito pequeno, por isso é fácil. Usei o methodName_conditions_result()esquema de Osherove e achei muito claro.

Mas, com os testes de integração, sinto que o nome seria muito longo e do que coloco no lugar methodName? Como nomeio classes de teste de integração?

Exemplos do mundo real de nomes de teste de integração são muito bem-vindos. Espero que as respostas também me ajudem a entender melhor esses testes.

Eu adoto uma abordagem um pouco diferente com testes de unidade e integração. Eu tento nomeá-los com base nos recursos, tanto quanto possível. Então, quando todos os testes forem aprovados, você poderá ver uma lista de todos os recursos que funcionam e não funcionam.

• canRegisterUser
• canHandleInvalidInput
• canRelayDocumentBetweenServers
• canCreateSchema
• canLoginUsingWebService
• canLoginUsingBasicAuth
• canDeleteDocument
• canAddDocument

Nem sempre é pragmático nomear os testes dessa maneira, mas pode ser muito útil, especialmente após a leitura de centenas de testes de unidade e integração. O nome geral da classe que contém esses métodos também deve ser indicativo dos recursos que estão sendo testados. Isso ajudará na organização.

Eu também sugiro nomear qualquer teste de unidade para correção de bugs com um prefixo exclusivo, como bugfix1002prova de que o bug foi corrigido.

Isso foi realmente escrito para ajudar nos testes de unidade, mas talvez você descubra que as mesmas regras se aplicam (mais ou menos) aos testes de integração:

Confira sete etapas !

Minha preferência é que, como quer que você chame, é realmente o nome da suíte de testes (nome do dispositivo elétrico em nosso cartão), o efeito que você está verificando e a mensagem de afirmação que precisa se destacar e esclarecer a causa do erro. Se você acha que é mais fácil com a nomeação de Asherove, então eu sinceramente endosso isso. Mas talvez o truque seja você preencher a parte "método" com o que faz a condição, resultado e exceção fazer sentido.

Fico feliz em ver um conjunto chamado "MakingADeposit" com um teste chamado "AccountDoesntExist" e um erro que diz "Exceção esperada de NonesuchAccount - nenhum recebido".

Como alternativa, se você não se importa de eu separar o nome do conjunto de testes com "::", estou bem com "AccountHandling :: MakingADeposit_AccountDoesntExist_ThrowsAnException"

O cartão também sugere que, se você não tiver um bom nome, continue em frente e dê um nome melhor quando um ocorrer (esperemos que bem antes de enviar o código ao CI).

Os testes de integração devem seguir algumas regras semelhantes aos testes de unidade, pois cada teste deve testar um aspecto de um requisito, mas testa o sistema como um todo. A classe deve nomear a coisa geral que está sendo testada, por exemplo, "TpcInputValidation" e a nomeação do método deve refletir expressivamente o que o teste está tentando fazer sem ser excessivamente prolixo, por exemplo, "shouldRaiseValidationErrorWithBadDates ()".

Os métodos devem testar um conceito do recurso e um grande número de afirmações pode indicar o contrário. (Ref. "Código Limpo: Um Manual de Artesanato em Software Ágil", p. 132, de Robert Martin).

Portanto, o problema é que um nome adequado de funcionalidade é muito longo para um nome de método? Eu sei que é estranho começar a escrever métodos de teste com nomes como registerAndValidateUnderageUniversityDriverWithCoverageSetA_test()e pode quebrar regras de compilador para nomes longos de métodos (o PL / SQL permite apenas até 30 caracteres - não sei se Java e C # impõem limites de nome abreviado, mas até se não o fizerem, ultrapassa um certo ponto e os nomes de métodos realmente muito longos podem ser úteis apenas para o código gerado que é lido / gerenciado por outro código gerado). Você pode tentar reduzi-lo, regValUnderageUnivDrvrWCovrgA_test()mas isso também é realmente horrível de ler. Uma opção que eu usei que eu não gostei, mas era a melhor escolha na época,underageUnivDrvr_test_01()e havia uma planilha mapeando os nomes dos métodos para uma descrição muito mais longa da funcionalidade sendo testada. Feio, mas funcionou. Você também pode documentar a descrição do teste na documentação da função no arquivo de origem, o que pode ser útil porque você pode gerar documentação dos testes diretamente do código, em vez de mapear entre a planilha e o código.