No meu trabalho, uso constantemente testes de unidade. E você? Na minha experiência, a maioria dos programadores é muito rara. Ao entrevistar candidatos a emprego em minha equipe, sempre faço a pergunta: "Você tem alguma experiência em testes?" E na maioria das vezes ouço em resposta: "Não". E se você perguntar por que, a resposta mais comum será: "O cliente não me deixou fazer isso".

Essa abordagem me surpreende. Você dirá ao construtor qual tipo de concreto escolher para construir uma casa? Ou mecânica de automóveis - qual parte do motor reparar e quais não, se o motor piscar no carro? É improvável, porque esses são problemas técnicos sérios, cuja solução deve ser confiada a um profissional. Um profissional possui as habilidades e ferramentas necessárias que lhe permitem resolver um problema mais rápido e mais barato.

Por que contar o dinheiro

O Código Civil tem o conceito de "salvar um contratado através da experiência e do conhecimento". Seu significado é que o trabalho é realizado por um profissional que sabe otimizar o processo, como fazer melhor, mas ao mesmo tempo mais barato. E desenvolvedores como profissionais devem oferecer ao cliente as melhores soluções pelo menos dinheiro.

Mas, na verdade, os programadores estão focados em outra coisa. Muitos deles têm certeza de que o desenvolvimento de software é um processo puramente técnico, que, é claro, tem seu valor, mas o trabalho do programador é escrever, não contar dinheiro. No entanto, na minha opinião, o desenvolvimento é principalmente um projeto econômico, por trás do qual há dinheiro e cálculos, e somente depois disso é uma tarefa técnica.

A lógica aqui é simples: os negócios - para os próprios clientes que nos pedem desenvolvimento de software para suas empresas - na verdade, não precisam de software. As empresas precisam de dinheiro, os benefícios que esse software trará.

Isso significa que os programadores não podem prescindir da economia do desenvolvimento, sabendo o custo das soluções técnicas e quais são ideais em termos não apenas de tecnologia, mas também de finanças.

O desenvolvimento de software geralmente não é a parte mais barata do negócio, mas o software de baixa qualidade pode levar a grandes perdas. Mesmo o tempo de inatividade leva a lucros perdidos e problemas de software podem levar a milhões de perdas. Portanto, o desenvolvedor como profissional deve estar confiante na qualidade do seu produto e garanti-lo ao cliente. Mas a qualidade do produto é o indicador mais importante. E o cliente deve saber que essa qualidade pode ser medida e ter confiança nela. E como exatamente é a tarefa do programador.

Eu, como muitos de meus colegas, acredito que os programadores não devem discutir soluções de engenharia com o cliente. Em geral, basta saber o que é importante para o cliente, que funcionalidade e para quais fins ele precisa. Quais decisões escolher são de responsabilidade do programador. E, no âmbito dessa responsabilidade, ele deve usar as melhores práticas de engenharia para um determinado projeto com custos economicamente justificados. Portanto, profissionais que sabem como tornar o processo de desenvolvimento mais barato ganham.

Qual teste é mais rentável

Uma prática que permite controlar a qualidade do produto é o teste. Mas qual teste é mais rentável? Para responder a essa pergunta, basta comparar vários parâmetros. Todos os testes podem ser condicionalmente divididos não apenas pelo tipo de tecnologia, mas também pela velocidade e, o mais importante, pelo custo.

Teste de unidade - teste de unidades de produção. Por unidades, quero dizer unidades de programa, dependendo do idioma representado por classes, funções e arquivos com menos frequência. Usando a abordagem TDD, o teste é inicialmente incorporado no processo de desenvolvimento do produto. Um projeto pode usar milhares desses testes para testar partes individuais de código. Eles têm um excelente indicador de velocidade - todo o conjunto de testes pode ser concluído em segundos. Estes são os testes mais baratos.

Testes de integração - testando 2x-3x ou mais unidades juntas. Pode haver centenas ou milhares desses testes em um projeto, dependendo do programador. Velocidade - segundos ou minutos para todo o conjunto de testes. O custo é superior aos testes de unidade.

Testes de aceitação simulam ações do usuário com um programa. Eles exigem a preparação de um ambiente operacional e, portanto, são complexos e caros. Quantidade por projeto - geralmente é feito um teste para uma história de negócios. A velocidade do trabalho é geralmente de dezenas de minutos a várias horas para todo o conjunto de testes.

O mais caro e difícil é o teste manual . Você precisa contratar uma pessoa, treiná-la, criar e fornecer um mapa do histórico de negócios para que ele teste o novo software. Esses testes levam vários dias para todo o conjunto de testes.

Qualquer tipo de teste requer preparação, bem como um certo investimento de dinheiro. E, para obter economia (e, portanto, benefícios), precisamos primeiro levar em consideração a velocidade dos testes e a complexidade de seu lançamento. Se o projeto não tiver testes automáticos, haverá apenas uma saída - o teste manual, o mais caro e o mais lento.

No entanto, a abordagem moderna para o desenvolvimento de software é um ciclo contínuo: em uma semana, uma nova funcionalidade ou uma nova versão é criada e verificada automaticamente ou manualmente. Ou seja, o produto muda com freqüência e todas essas alterações devem ser controladas para que o programador tenha certeza de que as funcionalidades novas e antigas funcionam bem. Portanto, o teste manual perde imediatamente em todos os indicadores.

Quanto aos diferentes tipos de teste automático, há três aspectos mais importantes a serem considerados.

Antes de tudo, é a confiabilidade - como é fácil interromper o teste (este é o melhor indicador para testes de unidade).

Em seguida, o ambiente necessário para executar os testes. Os testes de unidade são muito simples, eles mesmos criam um ambiente em torno da unidade em teste. Os testes de integração requerem um serviço que deve ser instalado, em execução etc. Os testes de aceitação requerem preparação, pois o aplicativo deve funcionar em seu ambiente.

E finalmente - cobertura (cobertura de teste). Os testes de unidade têm boa cobertura e são usados ​​durante todo o projeto. Os testes de integração são geralmente usados ​​em certas partes do projeto, ou seja, eles não cobrem completamente o programa. A cobertura dos testes de aceitação é pior - isso se deve à complexidade de escrevê-los e executá-los, na maioria das vezes eles cobrem os principais casos de negócios; isso representa de 20 a 40% do volume total do projeto.

Conclusão

Portanto, verifica-se que os testes de unidade estão liderando todos os indicadores dessa breve análise comparativa. Na minha prática, na maioria das vezes eu os uso, dá qualidade suficiente. Se os requisitos de qualidade aumentarem, passamos à aceitação. O uso de testes de integração depende do cliente, que pode querer testar determinadas partes do projeto.

Minha pilha de tecnologia atual é angular e .net. E se o teste do lado do servidor não suscitar grandes questões, o teste do aplicativo cliente ainda é, em muitos lugares, não óbvio para todos. Nos projetos de meus clientes, o número de testes de unidade varia de algumas centenas a vários milhares. No próximo artigo, tentarei compartilhar as principais técnicas para testar aplicativos angulares.