From 674cb6988ce80cea94f48a15bebe15aae2c3d5bd Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Tue, 14 Jan 2020 13:32:38 -0300 Subject: [PATCH] Working on the translation --- content/thoughts/reveries-about-testing.md | 156 ++++++++++++++++++ content/thoughts/reveries-about-testing.pt.md | 55 +++--- 2 files changed, 184 insertions(+), 27 deletions(-) diff --git a/content/thoughts/reveries-about-testing.md b/content/thoughts/reveries-about-testing.md index d8ea9b9..47ca54e 100644 --- a/content/thoughts/reveries-about-testing.md +++ b/content/thoughts/reveries-about-testing.md @@ -37,3 +37,159 @@ What I want to discuss: 3. The Explosion of Slow Tests; 4. Coverage; 5. Mocks. + +## TDD, Kent Beck Style + +What made me rethink the way I wrote tests was a video by Ian Cooper, called +["TDD, where it all go wrong"](https://vimeo.com/68375232). In this video, +Cooper points out that the Beck's book (which brought the whole TDD +revolution) says two things: + +1. Tests should run in an isolated way, nothing more, nothing less; +2. Avoid testing implementation details, test behaviors. + +The first point is what it means for a "unit test", meaning "run in +isolation", in the sense that the test does not depend on others. This way, +"unit tests" should be seen as "the test is a unit", not "testing units" -- +there are no "units", the test itself is a unit that doesn't depend on +anything else. + +The second point is that one should test behaviors, not the implementation. +This is a point that I see we fail a lot when we talk about testing every +class/function: What if the expected behavior is the combination of two +classes? Is it worth writing tests for both, if splitting the classes (or +functions) is just a matter of implementation/way to simplify the code? + +Also, another question for writing tests for every function and every class: +What we have know an application are their input channels -- which could be a +button in a graphical interface, an option passed in the command line or a web +request -- and the output channels; that way, the behavior is "given that +input in the input channel, I want this in the output channel", and everything +in the middle is implementation. And, for that transformation of something in +the input channel to the output channel, I may need a combination of +classes/functions; if I test every class/function, am I really testing the +expected behavior or the implementation? + +"But this looks like BDD!", you must be thinking. Cooper says this in the +video above: the idea of "test every class/function" became the norm, the +point of checking behavior had to be used somewhere else, what gave us ATDD +(Acceptance-Test Driven Development) and BDD (Behavior Driven Development). + +An example of testing behaviors: In the Django subreddit, there was a +question: [Should I write unit tests for Django's built in types?](https://www.reddit.com/r/django/comments/5bearg/should_i_write_unit_tests_for_djangos_built_in/) +The question is basically this: Django allows defining the database model, and +from that model create a form that I can put on my templates and validate the +incoming data; that way, if I defined that there is a field in my model called +"Year of Birth" -- which can only receive numbers -- and I create a form based +on the model, put it on my template, send the data back and Django will make +sure, from the type in the model, that the incoming request will have a number +in that field. Should I still write a test for that? + +The answer, though, is in take a step back and do the following question: Why +the year is a number? Obviously, 'cause years are defined as numbers[^1] and +the behavior of the field was defined way before we added the field in the +model. Also, supposed that for some reason, I need to store the field as a +string[^2]; if the type changes, the behavior should also change? Probably +not. + +When I ignored that the year should be a number 'cause "the framework will +take care of it", I ignored the expected behavior due the implemtantation. + +And "test behaviors, not the implementation". + +Non-factual, but an anecdote: In a project, we had an "alarm manager" where, +from an event, it should generate only a log entry, generate a log entry and +send a SNMP signal or, if the user set it, generate a log, send a SNMP signal +and turn on a LED in the front of the device. With that, we created a module +for the log, a module for sending SNMP signals and a module to turn on/off the +LEDs. Every module had tests, but we didn't feel comfortable with it yet. +That's when I suggested we write a test that would bring the service up and +send events to it, just like any other application in the system, and check +what would happen. That's when the tests finally made sense. (I'll still talk +about these tests in the coverage part of this post.) + +## Fast Tests, Slow Tests + +The counterpoint of the points above can be something similar to what Gary +Bernhardt says in his presentation [Fast Test, Slow +Test](https://www.youtube.com/watch?v=RAxiiRPHS9k). In it, Bernhardt mentions +that they changed the way the tests work, and that now they could run +hundreds of tests in less than a second (an example shows around 600 tests +being run in 1.5 seconds). + +What Bernhardt suggest is to write tests that checks online the models, with +no connection to the database or the views; tests for controllers with no +connection to the models or views; and tests for the views without the +controllers. + +Does that sound familiar (specially if you use a MVC framework, which puts +each of those layers in different classes)? + +Still about those tests, Bernhardt points that those "quick runs" help the +developers to test their to test their changes quickly (does that still sound +familiar?) but those tests do not replace the "integration tests". + +In that point, I have to ask: If the tests are written to check if a +controller can be run without being connected to the rest of the system, but +one still have to write the (so called) integration tests to verify that the +project is delivering whatever was promised it would deliver, what is really +being tested here? The impression I have from the type of test Bernhardt +proposes is more to check _architectural adherence_ than a quality test: Does +this controller follow the structure of not having any connections to the +database itself? Does this model has only functions related to the storage and +retrieval of data, without any logic? If that's it, what is the value for my +user if a controller doesn't access the database directly? + +It's not that I don't believe those tests have no value, but they give the +impression that, in the long run, they tend to become structurally very +similar while the (so called) integration tests tend to give more returns to +the quality of the project: Tests that defined an input and an expected result +tend to make sure that, in the long run, the functionality of the project will +still be the same. + +## The Explosion of Slow Tests + +The first thing that may pop up with a point like the above is that +"integration tests are slow and that will make the tests slow and make +developers less productive." + +Yes, integration tests are slow, specially 'cause there is a good leg of work +in creating the expected initial state, all the inputs as expected by the +I/O system (again, graphical interface, command line, web), run the whole +processing stack and verify the result. And yes, waiting all this time may end +up breaking the developer's flow. + +On the other hand, when a developer is working with some input, if it is a new +functionality/expected behavior, then there should be a test for this +behavior; if there is a change in the expected behavior, there should be a +test for the old behavior that needs to be changed. Running _just_ this test is +enough? No, but it should give a very good indication if the functionality is +working as expected. After making sure the behavior is correct, the developer +may execute the suite of tests for the thing being changed and let everything +else to the CI. + +For example, if I'm working in a new functionality to show an error message +when there is an invoice when the product is not in stock, I have to write a +test that creates the product, let it with no pieces in stock, make an invoice +and check for the error message. Once this test checks the behavior is +correct, I can run all the other invoice tests, and then let the CI validate +that I didn't break anything else else in the stock management module or even +the customer module (for some reason). + +And plugging with the first point, in order to do all the checks, I'd probably +need lots of functions/classes and test every single one of them will not make +sure the expected behavior is correct, but I'll get back to this later in the +coverage part. + +I have the impression that we don't use this kind of stuff due two different +problems: the first is that testing tools have a very bad interface for +running suite of tests (for example, running all the invoice tests and _only_ +the invoice tests); the second is that developers are lazy, and it's a lot +easier to run all tests than picking a single suite (not to mention organizing +said tests in suites to be run that way). + +## Coverage + +--- + +[^1]: Unless you want to use roman numerals, but anyway... diff --git a/content/thoughts/reveries-about-testing.pt.md b/content/thoughts/reveries-about-testing.pt.md index 5b45f64..6dbea7c 100644 --- a/content/thoughts/reveries-about-testing.pt.md +++ b/content/thoughts/reveries-about-testing.pt.md @@ -44,8 +44,7 @@ Agenda de coisas que eu vou comentar: O que me levou a repensar a forma como eu escrevia testes foi um vídeo do Ian Cooper chamado ["TDD, where it all go wrong"](https://vimeo.com/68375232) ("TDD, aonde é que a coisa deu errado"). No vídeo, Cooper coloca que o livro que -Beck escreveu (que deu origem a toda a revolução do TDD) diz apenas duas -coisas: +Beck escreveu (que deu origem a toda a revolução do TDD) diz duas coisas: 1. Testes devem ser executados de forma isolada, nada mais, nada menos. 2. Evite testar detalhes de implementação, teste comportamentos. @@ -60,15 +59,15 @@ O segundo ponto é que deve ser testado o comportamento, não a implementação. Esse é um ponto que eu vejo falhar um bocado quando pensamos em testar todo e qualquer classe e/ou função: E se o comportamento esperado é a combinação de duas classes? Vale a pena escrever testes para as duas, sendo que a questão de -separar em duas classes diferentes (ou duas funções diferentes) se referem ao -mesmo comportamento? +separar em duas classes diferentes (ou duas funções diferentes) é apenas uma +questão de implementação/simplicidade de código? Ainda, outro questionamento sobre testar todas as funções e todas as classes: o que sabemos de uma aplicação são os canais de entrada -- que pode ser por um botão em uma interface gráfica, um texto digitado na linha de comando ou uma requisição web -- e os canais de saída; assim, o _comportamento_ esperado é "dado essa entrada pelo canal de entrada, quero ter essa saída", e qualquer -coisa no meio é implementação. De novo, para fazer a transformação de uma +coisa no meio é implementação. E para fazer a transformação de uma entrada para uma saída específica, eu posso precisar de mais de uma função e/ou classe; se eu estiver testando cada uma das funções, eu estou realmente testando o comportamento ou a implementação? @@ -80,7 +79,7 @@ formato, o que deu origem ao ATDD (Acceptance-Test Driven Development, Desenvolvimento Guiado por Testes de Aceitação) e BDD (Behaviour Driven Development, Desenvolvimento Guiado por Comportamentos). -Um exemplo de como testar comportamento: No Subreddit do Django, foi criada +Um exemplo de testes de comportamento: No Subreddit do Django, foi criada uma pergunta: [Devo Escrever Testes Para os Tipos Built-In do Django?](https://www.reddit.com/r/django/comments/5bearg/should_i_write_unit_tests_for_djangos_built_in/) A questão se resume ao seguinte: Sabendo que no Django eu tenho tipos @@ -90,20 +89,20 @@ servem para validar os dados de entrada; assim, se eu defini que há um campo no meu banco chamado "Ano de nascimento" -- que só pode receber números inteiros -- e eu crio o formulário a partir do banco, coloco no meu template, recebo os dados de volta e o próprio Django vai garantir, pelo tipo do dado no -banco, que o resultado é um número inteiro, eu ainda preciso escrever um +banco, que o valor do campo é um número inteiro. Eu ainda preciso escrever um teste para isso? -A solução, no entanto, é dar um passo atrás e fazer a seguinte pergunta: _Por -que_ o ano é um inteiro? Obviamente, porque anos são definidos como números e, -portanto, o comportamento do campo foi definido bem antes do campo ser -adicionado na tabela. Ainda, imagine que, por algum acidente do destino, eu -precise guardar o ano como uma string[^1]; se o tipo foi alterado, o -_comportamento_ vai ser alterado também? Provavelmente não. +A resposta, no entanto, está em dar um passo atrás e fazer a seguinte +pergunta: _Por que_ o ano é um inteiro? Obviamente, porque anos são definidos +como números[^1] e, portanto, o comportamento do campo foi definido bem antes do +campo ser adicionado na tabela. Ainda, imagine que, por algum acidente do +destino, eu precise guardar o ano como uma string[^2]; se o tipo foi alterado, +o _comportamento_ vai ser alterado também? Provavelmente não. Quando eu ignorei que ano deve ser um número porque "o framework cuida disso pra mim", eu ignorei o comportamento esperado por culpa da implementação. -De novo, "teste comportamentos, não implementação". +E "teste comportamentos, não implementação". Embora não factual, uma anedota: Num projeto, tínhamos um "gerenciador de alarmes" onde, a partir de um evento, poderia ser gerado simplesmente um log, @@ -125,7 +124,7 @@ agora era possível executar centenas de testes em menos de 1 segundo (um exemplo mostra aproximadamente 600 testes em 1.5 segundos). O que o Bernhardt sugere é escrever testes apenas para os models, sem conexão -com o banco ou views; testes de controllers sem conexão com os models ou +com o banco ou controllers; testes de controllers sem conexão com os models ou views; e testes de views sem controllers. Soa familiar (principalmente em frameworks MVC que separam cada um destes em @@ -152,16 +151,16 @@ deixam a impressão que, a longo prazo, eles tendem a se parecerem, estruturalmente, muito parecidos, enquanto que (assim chamados) testes de integração tendem a dar mais retorno a longo prazo para a qualidade do projeto: Testes que definem uma entrada e um resultado esperado tendem a -garantir que, a longo prazo, o funcionando do sistema continuará sendo igual. +garantir que, a longo prazo, o funcionamento do sistema continuará sendo igual. ## Explosão de Testes Lentos A primeira consideração que surge numa declaração como a de cima é que "testes de integração são lentos e isso vai tornar os testes lentos e reduzir a -produtividade dos desenvolvedores. +produtividade dos desenvolvedores." Sim, testes de integração são lentos, principalmente porque há um bom trabalho -em criar o estado esperado, todas as entradas conforme esperado pelo sistema +em criar o estado inicial esperado, todas as entradas conforme esperado pelo sistema de I/O (de novo, interface gráfica, linha de comando, web), percorrer todo o percurso do processamento e verificar a saída. E sim, esperar esse tempo de execução pode acabar distraindo o desenvolvedor. @@ -219,7 +218,7 @@ uma questão sobre qual dos dois testes deveria ser eliminado. Mas nós tínhamo pelas duas validações. Um exemplo mais prático. Imagine uma classe que guarde dados de clientes de -um serviço web de compras[^2]: +um serviço web de compras[^3]: ```python class Client: @@ -232,7 +231,7 @@ está criando usuários sem parar, sem fazer compras, só pra sujar o banco; devemos bloquear todos os cadastros que tenham como nome do usuário apenas um nome. -Aí, pensando em SOLID[^3], o desenvolvedor altera o código para o seguinte: +Aí, pensando em SOLID[^4], o desenvolvedor altera o código para o seguinte: ```python def _multiple_names(name): @@ -251,7 +250,7 @@ class Client: Agora o que acontece é que quando um cliente é criado, são passadas as validações sobre o nome, e uma dessas é que o nome deve ter múltiplos -nomes[^4]. +nomes[^5]. Nova funcionalidade, precisamos de novos testes, certo? @@ -316,7 +315,7 @@ class Client: self.name = name ``` -Pronto, não tem mais validação[^5] e agora a Xuxa pode comprar. Mas ao rodar +Pronto, não tem mais validação[^6] e agora a Xuxa pode comprar. Mas ao rodar os testes: @@ -424,18 +423,20 @@ estão sendo criados. --- -[^1]: O porque vai ser uma string pode ser variado: por causa de um plugin de +[^1]: A não ser que você use anos com números romanos. + +[^2]: O porque vai ser uma string pode ser variado: por causa de um plugin de segurança, porque é feito um armazenamento num banco que não trabalha bem com inteiros, por causa de uma integração com sistema legado... -[^2]: Uma classe de entidades de clientes deveria ser bem mais completa que +[^3]: Uma classe de entidades de clientes deveria ser bem mais completa que essa, mas vamos deixar ela simples assim para fins de exemplo. -[^3]: E não, isso também não é SOLID de verdade, mas vamos deixar assim de +[^4]: E não, isso também não é SOLID de verdade, mas vamos deixar assim de novo para fins de exemplo. -[^4]: E alguém vai me passar o link do "Falácias que Desenvolvedores Acreditam +[^5]: E alguém vai me passar o link do "Falácias que Desenvolvedores Acreditam Sobre Nomes de Usuários" por causa disso. -[^5]: E sim, deveria alterar só o `_validate_name`, mas assim fica mais claro +[^6]: E sim, deveria alterar só o `_validate_name`, mas assim fica mais claro onde está o problema.