Browse Source

An analogy about integration tests and unit tests

master
Julio Biason 5 years ago
parent
commit
41a5edbad2
  1. 53
      content/thoughts/code-is-a-book-unittests-are-spell-checkers.md
  2. 54
      content/thoughts/code-is-a-book-unittests-are-spell-checkers.pt.md

53
content/thoughts/code-is-a-book-unittests-are-spell-checkers.md

@ -0,0 +1,53 @@
+++
title = "Code is a Book, Unit Tests are Spellcheckers"
date = 2020-02-14
[taxonomies]
tags = ["unit tests", "testing", "integration tests", "books", "code"]
+++
If we use an analogy for code as being the words in a book and the system
being built as the whole book, then what are unit tests?
<!-- more -->
I just found this analogy pretty good[^1]: You can to think about your code
as a book: Each module is a chapter, each class is a paragraph and each
function is a sentence.
In that analogy, were would unit tests sit?
To me, the unit tests are like spell checkers -- or, at least, the more modern
ones: Are you writing the proper words? Are your sentences grammatically
correct? The spell checker will take care of this.
But there is one thing that the spell checker won't do: make sure the chapter
makes sense in the whole context of the book. Escaping the analogy for a
moment, let me ask you this: Have you read "Les Misérables"? I did, and there
is one chapter in the middle of the book in which Victor Hugo discuss the
Battle of Waterloo. Although it makes sense in the historical point of the
story of Les Misérables, it makes absolutely no sense in the general story
itself -- no matter how well punctuate, correct in spelling and grammar it may
be.
This is a huge failure of unit tests: They don't see the whole. The whole is
given by reviewers of a book and integration tests of a system. Jumping back
to the analogy, when you have your integration tests defined by the system
requisites, anything that isn't being covered is a chapter that doesn't make
sense in the whole of the book.
In the long run, as writers will remember the times the spell checker
pointed a word was spelled wrong or a verb was in the wrong tense and, thus,
make it pop less and less, so does unit tests: In the long run, the ROI[^2] of
unit tests tend to go down, while the integration tests -- the ones that check
if the "chapter" makes sense in the story being told by the "book" -- tend to
go up.
And I just found the analogy so good for the way I see those two test
methodologies.
---
[^1]: ... but I lost the source of it. :(
[^2]: "Return Of Investment"

54
content/thoughts/code-is-a-book-unittests-are-spell-checkers.pt.md

@ -0,0 +1,54 @@
+++
title = "Código É um Livro, Testes Unitários São Corretores Ortográficos"
date = 2020-02-14
[taxonomies]
tags = ["testes", "testes de integração", "testes unitários"]
+++
Se nós usássemos uma analogia para código sendo as palavras de um livro e o
sistema sendo construído como o livro inteiro, o que seriam os testes
unitários?
<!-- more -->
Eu vi uma analogia excelente esses dias[^1]: Você pode pensar que o código que
você está escrevendo como um livro: Cada módulo é um capítulo, cada classe é
um parágrafo e cada função é uma frase.
Nessa analogia, onde é que os testes unitários ficariam?
Para mim, testes unitários são como corretores ortográficos -- ou, pelo menos,
os mais modernos: Você está escrevendo as palavras da forma correta? As suas
frases estão gramaticalmente corretas? O correto ortográfico vai cuidar disso.
Mas existe uma coisa que um corretor ortográfico não vai fazer: garantir que o
capítulo que você está escrevendo faz parte do contexto total do livro. Saindo
um pouco da analogia, deixe-me perguntar isso: Você já leu "Les Misérables"?
Eu li, e nele há um capítulo no meio do livro no qual Victor Hugo discute a
Batalha de Waterloo. Embora faça sentido no período histórico da história do
Les Misérables, o capítulo não faz o menor sentido para a história em si --
não importa o qual correta está a pontuação, as palavras estão certas e a
gramática correta.
Essa é a grande falha dos testes unitários: Eles não validam o todo. O todo é
dado pelos revisores de um livro e pelos testes de integração de um sistema.
Voltando a analogia, quando os testes de integração são definidos pelos
requisitos do sistema, qualquer coisa que não esteja coberto é um capítulo que
não faz sentido no conjunto do livro.
A longo prazo, como escritores começam a lembrar as palavras que foram
escritas erradas e os verbos no tempo errado apontados pelo correto
ortográfico, este começa a aparecer menos e menos, assim como testes
unitários: a longo prazo, o ROI[^2] tende a ser cada vez menor, enquanto
testes de integração -- aqueles que validam se um "capítulo" faz sentido na
história sendo contada no "livro" -- tende a ser maior.
E eu achei a analogia perfeita para a forma como eu penso sobre essas duas
metodologias de testes.
---
[^1]: ... mas infelizmente eu perdi a origem dela. :(
[^2]: "Return of Investment" ou "Retorno do Investimento".
Loading…
Cancel
Save