Anotação

O artigo fala sobre a forma não convencional, mas útil de testes, e também resume os resultados de sete anos de trabalho no desenvolvimento de testes.

Por que você precisa de testes de componentes?

Afinal, existem, digamos, testes de unidade que testam em detalhes as miudezas dos componentes. Eles verificam completamente se o componente funciona de acordo com a intenção do desenvolvedor. Mas muitas vezes isso é uma checagem de botões, e não como o traje fica como um todo. E nem sempre o comportamento concebido pelo programador coincide com o que o cliente queria.

E há, por exemplo, testes de aceitação. E eles eliminam todas essas deficiências. Mas, infelizmente, eles estão introduzindo novos. Eles são lentos, geralmente instáveis ​​e geralmente mansos. No entanto, eles indicam apenas um problema, mas não o localizam.

Obviamente, surge a necessidade de testes intermediários, que serão a média de ouro entre os testes de unidade e de aceitação. Esse meio termo pode ser testes de componentes.

O que são testes de componentes?

Estes são testes para a API do componente público. Assim, eles são escritos no mesmo idioma que o componente. Objetivo do teste:

• verifique a conformidade dos componentes com seus contratos
• verificar conformidade
  Este último é especialmente importante, pois testes de unidade geralmente são escritos com base nas expectativas do desenvolvedor, mas aqui você precisa verificar as expectativas dos clientes.

Obviamente, os testes de componentes fazem sentido quando você tem componentes dedicados com uma interface extensa. Por exemplo, uma biblioteca dinâmica ou um objeto COM. Em seguida, testes de componentes fornecerão o efeito máximo.

Prós dos testes k:

• Dê estabilidade ao desenvolvimento. Obviamente, uma verificação abrangente das interfaces públicas permite manter o componente de uma forma mais ou menos eficiente.
• Localize problemas com precisão. Mesmo que o teste do componente seja bastante geral, ele sempre pode ser depurado em profundidade, chegando rapidamente ao código de batalha. Nesse caso, o ambiente de teste será mínimo e configurado automaticamente.
• Acelere o desenvolvimento com um número crítico de desenvolvedores. Os programadores são conhecidos por serem como cavalos. Se um cavalo puxa uma carroça com capacidade para 1 litro. s., então oito cavalos são puxados com uma capacidade de apenas cerca de 4 litros. s E a adição de outro desenvolvedor à equipe (especialmente no final do projeto) geralmente não apenas não acelera, mas também diminui a velocidade. Embora a adição de um desenvolvedor de teste de componentes seja sempre uma vantagem, uma vez que age de forma relativamente independente da equipe: faz testes (essencialmente externos), acelera a construção da compilação, otimiza arquivos de montagem etc.
• Esclareça (e verifique) os requisitos do cliente. Como o desenvolvedor dos testes de componentes não está vinculado à implementação, ele é menos afetado pelo efeito "Eu sei como fazer isso sozinho". No caso de um requisito ambíguo, o desenvolvedor comum costuma fazer o que for mais conveniente (mais interessante, mais rápido, mais fácil). Enquanto o desenvolvedor de ct, nesse caso, está inclinado a especificar exatamente o que é esperado pelo cliente.
• Relativamente estável e relativamente rápido (em comparação com testes manuais e testes automatizados através da interface do usuário).

Contras dos testes K:

• Hora de desenvolvimento e suporte. Obviamente, a versão alfa do produto, se passar parte do tempo escrevendo testes de componentes, aparecerá mais tarde. Haverá um ganho em geral? Haverá um lançamento mais cedo? Esta é uma boa pergunta. Minha opinião: ao desenvolver com testes de componentes, o lançamento será lançado aproximadamente ao mesmo tempo. Mas - com menos rumores e mais previsível em termos de tempo. O tempo de desenvolvimento aumentará naturalmente, o tempo de correção e estabilização será reduzido. Como a segunda parte é muito menos previsível, sua redução terá um efeito benéfico na quantidade de processamento e aborrecimentos. No entanto, esta é apenas a minha experiência, e a realidade pode ser diferente. É possível que o tempo alocado para testes de componentes seja inutilmente gasto na duplicação de testes de unidade existentes.
• Menos permutabilidade. A separação de papéis aumenta a eficiência, mas reduz a intercambiabilidade. Os desenvolvedores raramente desejam aprofundar-se nos testes de componentes, que podem ter (ou simular) um ambiente bastante complexo. Os desenvolvedores de testes de componentes estão longe de conhecer o código de batalha tão bem que ele pode ser facilmente editado.
• Duplicação irritante. Com bons testes de unidade, os testes de componentes geralmente acabam sendo redundantes. Isso é irritante e questiona sua necessidade. A coordenação de planos de unidades e testes de componentes ajuda, mas geralmente a duplicação não é completamente eliminada.
• A necessidade de seguir o fluxo de trabalho correto. Após o recebimento dos requisitos, a tarefa deve ser colocada simultaneamente no desenvolvedor e no desenvolvedor dos testes. Então eles terminam o trabalho quase ao mesmo tempo. O componente é executado através de testes, os erros são capturados e corrigidos rapidamente e um produto acabado mais ou menos é usado para sair. Nesse caso, os benefícios dos testes de componentes são maximizados. Mas muitas vezes acontece que os prazos são profanos há muito tempo, todos são abandonados para escrever apenas código e o componente é enviado para testes manuais sem testes. E só então eles convidam o desenvolvedor dos testes - eles dizem que não é bom que o código sem os testes tenha sido lançado, seria necessário adicioná-los. Nesse caso, a maioria dos erros é encontrada pelos testadores manuais, os desenvolvedores fazem correções às cegas (ou testam as alterações manualmente), e os testes pós-factum encontram apenas um pequeno número de erros (o que afeta negativamente a moral do escritor). Esse uso de testes de componentes é inútil, na melhor das hipóteses, e é difícil garantir isso.
• Existem poucas pessoas adequadas. O desenvolvedor de testes de componentes deve, por um lado, poder escrever código no idioma do componente (e isso, por exemplo, C ++). Além disso, se o ambiente para iniciar o componente for extenso, o código poderá ser bastante complicado. Por outro lado, seja capaz de testar meticulosamente o trabalho de outra pessoa. Não existem muitas pessoas assim, e elas geralmente vão imediatamente para os desenvolvedores. Mas ainda existem essas pessoas e a próxima parte sobre elas.

Resumo 1

Os testes de componentes são bons, mas somente se você tiver todas as condições para eles: uma API pública ampla, o fluxo de trabalho certo e as pessoas certas na equipe.

Como é ser um SDET?

Obviamente, o SDET - Engenheiro de Desenvolvimento de Software em Teste é um candidato ideal para escrever testes de componentes. Ele sabe escrever código e sabe pensar em testes. Ele também fornece uma segunda opinião, o que também melhora a qualidade dos testes e do código. Tudo isso parece interessante e tentador - talvez você já queira ser um. Aqui, explicarei brevemente como o trabalho do SDET difere do trabalho de um desenvolvedor puro.

Vantagens de trabalhar com SDET:

• Novo código. Quase sempre, o SDET grava testes do zero. E muitas vezes, um ambiente é escrito do zero. É muito bom e oferece grandes possibilidades de criatividade.
• Baixa dependência do código legado. Não importa o quão terrível o código de batalha seja, os testes podem ser realizados de forma competente e bonita. Obviamente, código mal projetado gera testes feios, mas ainda assim eles podem ser feitos em uma ordem de magnitude melhor que o próprio código.
• Refatoração mais frequente. Alterações nos testes são muito menos perigosas; portanto, elas são acordadas com mais frequência. Esta é uma boa oportunidade para trabalhar com bugs e praticar a escrita de código limpo por meio da refatoração.
• O desenvolvimento do pensamento crítico. Os autotestes são uma pesquisa interessante sobre como quebrar o código de outra pessoa. Além disso, a pesquisa não é estúpida, não fica de fora e cutuca, mas com a ajuda da lógica, da combinatória e da capacidade de ver vulnerabilidades. Além disso, uma vez criada, uma verificação continuará a funcionar para você constantemente.
• Desenvolvendo a capacidade de testar código. No treinamento de combate corpo a corpo, eles costumam dar palavras introdutórias: "agora trabalhamos apenas com nossos pés; agora trabalhamos apenas com nossas cabeças". O uso de apenas um mecanismo (no nosso caso, autoteste) permite aprimorar o domínio.
• Menos número de rumores. Os SDETs são muito menores no final de semana. Eles não precisam trabalhar urgentemente para corrigir bugs críticos. Bem, eles têm uma chance muito menor de cometer um erro grave.

Contras de trabalhar com o SDET:

• Baixa complexidade de codificação. O código de teste geralmente é ainda mais simples que o código de batalha. Pré-condições, chamando o código de batalha, pós-condições - e assim por diante para cada teste. O código para criar o ambiente é mais complicado, mas ainda não chega ao combate. Seleção de algoritmos ideais, projetando estruturas de dados complexas, construindo hierarquias de classes - geralmente tudo isso passa pelo desenvolvedor de teste.
• A experiência está ganhando mais lentamente . A variedade e complexidade de situações nas quais o desenvolvedor de testes se enquadra é muito menor. Falha na linha de montagem, testes em vermelho, às vezes despejos - esse é o conjunto principal com o qual você normalmente tem que trabalhar. O desenvolvedor tem muito mais problemas: começando pelas variações de vinculação e montagem, continuando com falhas em um cliente específico e nos dumps criados, terminando com a descoberta de erros nas bibliotecas do compilador e de terceiros. E não apenas ...
• Uma grande diferença no estilo de teste com os desenvolvedores. Geralmente, os SDETs preferem testes expressivos compactos que permitem criar um ambiente complexo em apenas algumas linhas, e as verificações atômicas no estilo são iguais / diferentes (ou seja, o requisito é atendido ou não). Às vezes, trata-se de sua DSL. Simplesmente, os desenvolvedores preferem testes com o ajuste fino do ambiente e vários testes de vários aspectos do comportamento do programa, o que leva a testes com várias linhas. Às vezes, trata-se de copiar e colar (que mesmo os melhores desenvolvedores não consideram pecado neste caso). Aqui, você pode discutir por um longo tempo a melhor ou mesmo escrever um artigo separado, mas o fato é que, quando um desenvolvedor tenta modificar os testes SDET (ou vice-versa), isso geralmente leva a longas e pouco produtivas discussões.
• Abaixo está a "nota". Talvez devido ao código mais simples e menos responsabilidade, mas no final não seja importante. Geralmente é assim.
• Mais difícil mudar para uma nova posição. O SDET pode muito bem colocar a pergunta na testa: você está escrevendo testes há tanto tempo, ou seja, acabou de chamar funções e comparar os resultados - você pode escrever código real? Você conhece todas as armadilhas do idioma? Você resolveu problemas complexos? Você teve que desmontar insetos ou lixões ornamentados? Existe alguma experiência com multithreading? Afinal, você tem ambições?

Resumo 2

Como uma pessoa que trabalhou como desenvolvedor por muitos anos, depois foi para SDETs por vários anos e depois voltou ao desenvolvimento novamente, posso dizer o seguinte.

Eu recomendo gastar um SDET por pelo menos um ano ou dois. Esta é uma experiência muito gratificante para qualquer desenvolvedor. Mas ficar lá, na minha opinião, não vale a pena.