<imgsrc="_images/mini-hitler.jpg"alt="Me chamaram de Mini Hitler"/>
</section>
<section>
<imgsrc="_images/filho-do-capeta.jpg"alt="... mas hoje eu vim botar os filho dos outro no go horse."class='stretch'/>
@ -103,6 +102,14 @@
<imgsrc="_images/patriarch.jpg"alt="... e eu sou meio não-ortodoxo sobre testes."/>
</section>
<asideclass="notes">
Um aviso: muitas das coisas que eu vou discutir aqui,
não são as coisas que normalmente são discutidas quando
se fala sobre testes.
Fiquem avisados que muitas pessoas não concordam comigo.
</aside>
</section>
<section>
@ -111,7 +118,7 @@
<ul>
<li>TDD Kent Beck Style.</li>
<li>Fast Test, Slow Tests.</li>
<li>Explosão de testes.</li>
<li>Explosão de testes lentos.</li>
<li>Coverage.</li>
</ul>
</section>
@ -120,6 +127,14 @@
<section>
<imgsrc="_images/tdd-where-it-went-wrong.png"alt="TDD: Where it went wrong"class="stretch"/>
<p>Ian Cooper: <ahref="https://vimeo.com/68375232">"TDD, where did it all go wrong"</a></p>
<asideclass="notes">
Boa parte das coisas que eu vou discutir aqui foram
influenciadas por esse video do Ian Cooper, em que
ele discute coisas sobre TDD no estilo discutido
por Kent Beck, que foi quem escreveu o livro que
trouxe o termo "TDD" para as massas.
</aside>
</section>
<section>
@ -131,13 +146,44 @@
<li>"Run in isolation", nothing more, nothing less.</li>
<li>"Avoid testing implementation details, test behaviours"</li>
</ul>
<asideclass="notes">
No seu livro, Kent Beck diz que "unit tests"
significam "rodam de forma isolada, nada mais, nada
menos". Esse é o _único_ significado de "unit
test"; "testes unitários" e não "testes de
unidade", na tradução correta.
Outra coisa que Kent Beck fala no seu livro é que
devem ser testados comportamentos, não
implementação. Pensem um pouco sobre isso: Se
estamos testando comportamento ao invés de
implementações, como é que podemos escrever um
teste de um objeto ou uma função? O que sabemos é
que uma aplicação tem um protocolo de entrada de
dados (terminal, web, GUI) e um protocolo de saída
(provavelmente o mesmo que o de entrada, no sentido
contrário) e como essa aplicação tem que se
comportar com relação à entrada.
</aside>
</section>
<section>
<h2>TDD</h2>
<p>Discussões como "qual a unidade a ser testada" é que geraram
coisas como BDD e ATDD (Acceptance Test-Driven Development).</p>
<p>
Discussões como "qual a unidade a ser testada" é
que geraram coisas como BDD e ATDD (Acceptance
Test-Driven Development).
</p>
<asideclass="notes">
Se vocês pensarem, essa questão de como uma
aplicação deve se comportar é exatamente que fez
com o BDD (behaviour driven development) e ATDD
surgiram -- e eles não são diferentes do que o que
Kent Beck quis dizer com o TDD.
</aside>
</section>
<section>
@ -145,9 +191,31 @@
<p>Reddit: <ahref="https://www.reddit.com/r/django/comments/5bearg/should_i_write_unit_tests_for_djangos_built_in/"target="_blank">Devo escrever testes para a validação interna do Django?</a></p>
<asideclass="notes">
Uma boa pergunta uma vez surgiu no Reddit do Django
foi "Devo eu criar um teste para um campo inteiro
quando o Django já verifica que um campo inteiro
não possa ter caracteres?"
</aside>
<h1class="fragment">SIM!</h1>
<pclass="fragment">... bom, talvez sim.</p>
<asideclass="notes">
A questão do teste não é relacionado com o tipo de
campo, mas o _significado_ do campo.
Exemplo, se o campo for "ano de nascimento",
obviamente "AAAA" não é um ano válido, e o Django
vai barrar isso se eu definir o campo como inteiro.
Mas eu poderia usar um campo caracter (por um
motivo qualquer) e eu teria que testar por ser um
inteiro.
Mas porque eu usaria um caracter ao invés de um
inteiro?
"Teste comportamento, não implementação".
</aside>
</section>
<section>
@ -156,7 +224,8 @@
<p>Nossos testes End-to-End.</p>
<asideclass="notes">
Explicação do que aconteceu com os testes do gerenciador de alertas.
Julio Biason
5 years ago