-
Ok, então vamos começar com esta próprias mãos sobre a abordagem do teste. O teste é uma
-
coisa que eu, tenho que admitir que é realmente apenas três ou quatro anos atrás que eu comecei a
-
religião sobre ele, e o que eu quero dizer com isso é que eu sempre meio que, você sabe, foi-me dito
-
que era importante, eu acreditava era importante, eu meio que tentei fazê-lo, mas
-
fazê-lo desta maneira realmente mudou minha vida e espero que isso vai mudar a sua também e
-
não, eu não estou na campanha presidencial, isto é, de qualquer forma, ok Então, vamos começar
-
falando sobre testes de unitário. Há algum background no livro sobre as diferentes
-
tipos de testes. Iremos nos concentrar inicialmente em testes unitário e um pouco sobre testes
-
funcionais e como acontece com tantas coisas nesta classe, há uma sigla útil que ajuda
-
a lembrar que testes unitários devem ser bons. Assim, uma delas é que deve ser rápido,
-
não deve demorar muito tempo para executá-los. Devem ser independentes, o que significa
-
que a execução de um teste antes de outro não deve fazer qualquer diferença. A ordem
-
em que você executá-los não deve ter dependências entre si. Eles devem ser
-
repetível, se um teste encontra um bug, ele deve achar que bug o tempo todo. em alguns
-
casos é fácil de fazer isso, em outros casos é surpreendentemente sutil. Auto-verificação.
-
O teste utilizado para significar não, que há muito tempo para muitas empresas, é que o software
-
foi jogado por cima do muro a este departamento de QA. E então as pessoas em QA seria
-
classificar manualmente de cutucar o software e fazer as coisas. E sim esse trabalho. Sim, isso
-
funcionou. Isso, nós não fazemos mais isso, certo ? O código de teste tem que conhecer a si mesma se
-
ele passou ou falhou. Nenhuma intervenção humana deve ser requerida para tomada dessa decisão.
-
E oportuna. Isso significa que o teste deve ser escrito direita em torno do
-
mesmo tempo, o código foi escrito. Se as alterações de código, a mudança de teste imediatamente. NA
-
verdade, na verdade estamos indo fazê-lo ainda mais agressiva. Nós vamos escrever o teste
-
primeiro, antes de o codigo estar escrito. Então, isso é tão oportuna como você pode ser. É como
-
entrega túnel do tempo. Então, o que significa isso? Porque, se os testes são rápidos, por que
-
você quer isso? Bem, é porque você pode executar um subconjunto dos testes o tempo todo. Se
-
você tem milhares e milhares de testes de unidade, que não é incomum, mesmo em um
-
projeto de tamanho médio. Pode demorar, você sabe, um ou dois minutos para executar o
-
teste completo de varredura, e que realmente te atrasa. O que você quer é ser capaz de
-
executar rapidamente apenas os testes que se aplicam ao pedaço de código que você está trabalhando, e
-
não tem esse tipo de levá-lo fora do ritmo. Independente. Por essa mesma razão,
-
você quer ser capaz de executar qualquer subconjunto e você quer ser capaz de executá-los em qualquer
-
ordem. Então, seria ruim se houvesse um conjunto de testes que só funcionasse corretamente
-
desde que você fez alguns outros testes na frente deles. Repetitivo. Você sabe, mais uma vez, execute-o
-
N vezes, obter os mesmos resultados. Se você quer isolar bugs, e ativar a depuração
-
automático, repetibilidade é essencial. Auto-verificação, como eu disse. Nenhum ser humano
-
Nenhuma verificação humana da saída. Isso significa que você pode classificar de ter testes executados em
-
segundo plano o tempo todo. E sempre que você muda algo que quebra alguma coisa 25
-
milhas de distância em outro pedaço de código, alguns testes irão detectar esse fato, e buscá-lo
-
e trazê-lo à sua atenção. E oportuna, como eu disse, vamos usar
-
test-driven development, onde escrever o teste antes de escrever o código. Assim,
-
a sigla céu. Nós vamos estar usando nossa especificação, o que eu penso como um domínio
-
específico para escrever testes. Para aqueles de vocês que não estão familiarizados com
-
o DSL, o que é, basicamente, como uma linguagem de programação pequena que só faz um
-
pequeno número de coisas dentro de um domínio de tarefas. Por isso, não tento ser geral,
-
e nós temos realmente visto exemplos de eles até agora. As migrações são um tipo de DSL,
-
certo. Há um, um pequeno conjunto de declarações cujo único trabalho é a de expressar
-
alterações no esquema de banco de dados. Agora migrações acontecer de ser um D.S.L. Isto é
-
Que está incorporado em Ruby. Significado, as migrações são apenas código Ruby, mas eles são estilizada para
-
parecer com as tarefas que eles fazem. E, de fato, veremos que a nossa especificação é, um exemplo
-
similar. Então, nós vamos chamar aqueles uma DSL interna. Ele é implementado dentro de outro
-
língua. As expressões regulares são outro DSL interna, certo? Há, como, este
-
vocabulário pouco sub coisas que você pode fazer em expressões regulares. Exemplo diferente
-
de um DSL externo ou de um stand-alone é SQL. Sequela consultas para bancos de dados, à direita,
-
que, é própria língua e aqueles de vocês que trabalharam com outros frameworks
-
antes de vir para Rails, geralmente o que você acaba fazendo é essencialmente a escrita de consultas
-
sequela e, em seguida, fazer passar uma string para alguém, certo? Então isso é um exemplo muito claro
-
de lidar com diferentes idiomas. [Tosse] Assim, em R spec, cada teste
-
é chamado de spec, para uma especificação. Surpreendentemente, eles habitam um diretório
