Sim, você ouviu direito - isso mesmo! Na comunidade de TI, é firme a opinião de que todos esses testes ajudam de alguma forma, mas será mesmo assim? Você tentou pensar criticamente e analisar você mesmo essa sabedoria convencional? Hipsters inventam um monte de paradigmas - TDD, BDD, SDA, polícia de trânsito - apenas para criar a ilusão de atividade agitada e de alguma forma justificar seu salário. Mas pense no que acontecerá se você (ou seus programadores) começar a dedicar todo o seu tempo exclusivamente para escrever código? Existe uma área separada para testes e divisões inteiras. Você não força os programadores a escrever requisitos, não é? Então, por que eles deveriam escrever testes? Todos aqueles que concordam e discordam, por favor, entrem no post, onde irei mostrar claramente que os testes de unidade (e integração) são um grande mal!
De onde veio o teste?
Nos tempos antigos, não havia nenhum teste. Não havia nem mesmo essa direção, muito menos termos como bloco (unidade) e teste de integração. E sobre todos os tipos de e2e e, Deus me perdoe, pipelines, geralmente fico quieto. E tudo isso porque, na verdade, ainda não havia nada para testar. Naqueles anos, os engenheiros de software estavam apenas tentando criar os primeiros computadores.
Como todos sabemos, os primeiros computadores eram gigantescos em tamanho, pesavam dezenas de toneladas e custavam mais do que o seu Apple MacBook Pro Retina 4k 32Gb RAM 1Tb SSD Touch Bar USB Type-C. E, naquela época, os desenvolvedores tinham muito medo de que algo desse errado durante o trabalho. Acho que você conhece a história da origem do termo "bug" - se de repente não, então leia , é muito interessante. E como os programadores tinham medo de tudo, eles criaram testes de unidade.
Os tempos mudaram, os computadores também mudaram. O teste também mudou. Além dos testes unitários, surgiu também toda uma área, que mais tarde ficou conhecida como Quality Assurance.
Mas os desenvolvedores também mudaram. Hoje em dia, torna-se ridículo pensar que alguém tem medo de executar um programa, pois isso pode colocar fogo no servidor. Em 2020, os programadores não têm medo de lançar seus programas. E se não há medo, por que testar?
Realidades modernas
Repito minha pergunta - se o seu MacBook (ou Xiaomi) não explodir devido a um bug no código, por que testar então? Basta iniciar e curtir o resultado. Antecipando sua indignação com o alto custo de erros para o cliente - deixe que pessoas especialmente treinadas façam os testes.
. , . - . . -, Quality Assurance – , ¯\_(ツ)_/¯
, Software Development, Unmistakable Development. .
-, : «, , ». ? ?
. – . . , , , ?
: « » - .
, master, , . pull request , – . , , .
:
, .
, . , , , , . , -, .
.
– . – . ? .
, . , . , . , .
, , . , QA , . , – , .
– . .
Unit-testing, Integration Testing, End 2 End, Pipelines, CI, CD – , ? , , .
. , , e2e , . – .
- CI CD – . devops, . - , - , – .
. , – . – . – bash. … , .
Delivery In Time
: DIT – Delivery In Time. ( ****), . . , , . DIT , – , . , . , : – , – , . , , .
DIT . , ( ), . . , , Quality Assurance . .
:
– ?
– .
– .
– … , 1000 .
. , .
, DIT , , . , . - (, , , ), .
: – , . - , , , . .
, . .
- , (, , ) . , , - . , ? , , .
. , . , – . , , , .
. , , . , ? , , , ? , . , - . – .
. (, 2 ) – . , , . , , . . .
, ? . . , .
. . – , – . - , . , . .
!
, , :)
, . , . , . , , 15%. . , .
? / 80%? - 30? – , ?
, . , , :)
E, aproveitando: se você gostou desse formato, então convido você para o meu blog de um péssimo desenvolvedor (muitas vezes mentira) VK público , onde posto de vez em quando posts sarcásticos semelhantes, que muitas vezes são inconvenientes de postar aqui.