Semana 4 Gerência e Qualidade de Software - EES201 - _

Prévia do material em texto

O teste de unidade é o nível de teste que trata do menor elemento do software. Em softwares Orientados a Objetos (OO), não há um
consenso de qual é a unidade: o método ou a classe. Por um lado, o método é o menor elemento que pode ser testado; por outro, o
método só faz sentido no contexto de uma classe.
Por mais que essa discussão seja teórica, ela é importante para definir qual é o escopo do teste de unidade. Como discutido por Delamaro,
Maldonado e Jino (2016), na OO podemos pensar em testes intramétodos, intermétodos, intraclasse e interclasse. Se pensamos que a
unidade é o método, então o teste de unidade envolve apenas testes intramétodos; se pensamos que a unidade é a classe, então o teste
de unidade envolve testes intermétodos e intraclasses, além de teste intramétodos. Essa divisão é importante para definir as
responsabilidades do time de desenvolvimento. Dependendo da empresa, uma equipe de testes pode ser a responsável pelo teste de
integração e, portanto, o desenvolvedor deveria fazer apenas o teste de unidade. Mas, se a empresa não possui uma equipe de testes – o
que é bastante comum –, então não há discussão: o desenvolvedor é quem faz os testes de unidade e o de integração.
O mais comum, no mundo real, é o desenvolvedor ser o responsável por pelo menos os testes intramétodos, intermétodos e intraclasse.
Ou seja, na prática o desenvolvedor é o responsável por testar a classe – tanto faz se ela é a menor unidade do teste ou não[1]. Então essa
será a preocupação que teremos na disciplina.
 
AUTOMAÇÃO DE TESTES
Testes podem ser executados manualmente, semiautomaticamente ou automaticamente. A tendência atual é automatizar
o máximo possível. O motivo disso é bem simples: com testes automáticos é mais simples testar, e o time de desenvolvimento pode testar
com frequência – o que aumenta a chance de se encontrar defeitos.
Pensando especificamente em testes de unidade, existem alguns princípios que devem ser considerados ao automatizar os testes. Alguns
desses princípios são (Meszaros, 2007):
TEXTO-BASE
Teste de unidade automatizado
com o jUnit | Fábio Levy
Siqueira
Projete o software para ser testável. Um bom software precisa ser fácil de testar.
Comunique a intenção do teste. Testes precisam ser fáceis de entender e de manter (não se esqueça de
que temos que fazer manutenção também dos testes ao fazer uma mudança no software). Por isso é
importante que os nomes dos testes mostrem claramente a intenção do teste.
Não modifique o sistema para testar. Um erro bastante comum de testadores iniciantes é alterar o código
“só para realizar os testes” – como, por exemplo, inicializar uma variável com um valor especial para facilitar
o teste. Essa mudança pode fazer com que o teste deixe de ser automático (tornando-se semiautomático) –
já que é preciso alterar alguma parte do código antes de testar. O pior é que podemos esquecer de alterar o
código para o valor correto após executar os testes! Ou seja, ao testar, podemos introduzir um defeito. Um
outro erro bastante comum é abrir brechas na classe para facilitar os testes (um exemplo simples: criar um
método auxiliar na classe só para ser usado para o teste). Porém, essas brechas podem ser usadas por
desenvolvedores desavisados ou mesmo por alguém mal-intencionado. Note que o princípio “projete o
software para ser testável” não é contraditório com esse princípio: um software bem projetado para testes
não tem brechas!
Mantenha os testes independentes. Um teste não deve depender do resultado de um outro teste. Se
houver dependência, vários testes podem não passar ao mesmo tempo por um único motivo, o que dificulta
a identificação do defeito.
Isole a unidade sendo testada. Se o teste envolver uma outra unidade, um defeito nela pode propagar
para a unidade sendo testada – por mais que a unidade sendo testada esteja correta. Por isso deve-se
isolar a classe e o método sendo testado. Pensando em classes, é normal que haja dependência entre
classes; veremos mais adiante como lidar com isso.
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftn1
Por mais que você deva se guiar por esses princípios, às vezes é bastante difícil segui-los completamente. O interessante é que existem
vários frameworks de teste que nos ajudam a criar bons testes – e provavelmente nos próximos anos aparecerão novos frameworks que
nos ajudarão ainda mais a realizar testes automáticos seguindo esses princípios. Nesta aula você aprenderá a usar o framework mais
simples – e clássico – de teste de unidade: o jUnit.
 
JUNIT
O jUnit é um framework e um ambiente de testes de unidade automáticos para Java (existem similares ao jUnit para outras linguagens de
programação). Ele é praticamente um padrão para Java e, por isso, muitos IDEs oferecem nativamente suporte ao jUnit. Apesar de já estar
disponível a versão 5 do jUnit, a maioria dos IDEs ainda usa a versão anterior. Por isso este documento tratará do jUnit 4 – e o exercício
também deverá ser feito nessa versão.
Procure no seu IDE favorito como criar um teste de unidade usando o jUnit[2]. Alguns pontos importantes ao criar o teste no seu IDE
favorito:
Para criar um teste é necessário apenas declarar um método na classe de teste, colocando a anotação @Test antes da declaração do
método. Por exemplo:
import org.junit.Test;
public class ExemploTest {
 
 @Test
 public void metodoDeTeste() {
 ... // código
 }
}
Minimize a sobreposição dos testes. Testar a mesma coisa várias vezes significa desperdício de tempo –
seja tempo do desenvolvedor que fez o teste, do mantenedor que terá que corrigir esse teste, ou de todos
os desenvolvedores que terão que executar esse teste. Só como observação, dependendo do tamanho do
projeto, rodar todos os testes automáticos pode demorar muito tempo - dependendo do caso, várias horas!
Por isso se sugere que a suíte de testes executada pelos desenvolvedores demore no máximo alguns
minutos, e evitar a sobreposição ajuda a diminuir esse tempo.
Minimize código não testado. Os testes devem cobrir uma boa parte do código. Algumas empresas
definem que os testes devem exercitar no mínimo 80% do código da classe (80% de cobertura). O ideal é
seguir um critério de teste estrutural como todos os nós ou todas as arestas.
Mantenha a lógica de teste fora do código de produção. O software rodando no ambiente real (chamado
de ambiente de produção) não deve ter testes. Além dos testes impactarem desnecessariamente no tempo
de processamento e na memória necessária para o software em produção, os testes podem causar defeitos
ou mesmo abrir brechas.
Verifique uma condição por teste. Cada teste deve testar apenas um único comportamento. Com isso,
fica fácil identificar o defeito, facilitando a depuração.
Coloque o código fonte dos testes em uma pasta diferente do código fonte da aplicação (pelo
princípio Mantenha a lógica de teste fora do código de produção).
Coloque a classe de teste no mesmo pacote da classe a ser testada. Isso dá acesso aos métodos
protegidos e friendly (acesso por classes no mesmo pacote), o que facilita o teste. Note que os IDEs
permitem que a classe de teste fique em uma pasta diferente da classe a ser testada e, ao mesmo tempo,
no mesmo pacote.
Crie uma classe de teste por classe. Isso organiza os testes. A convenção é usar o mesmo nome da classe
testada com um sufixo Test ou Teste / Testa. Por exemplo, para testar a classe Pedido deve-se criar a
classe , ou [3].
https://junit.org/
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftn2
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftn3
Para fazer isso é necessário fazer o import de , que define a anotação.
Para realizar os testes são usados alguns métodos de apoio que verificam uma asserção (afirmação que precisa ser verdadeira). Os
principais métodos são: 
Método ExplicaçãoExemplo
assertTrue(boolean condição)
Verifica se a
condição é
verdadeira. Se for
falsa, o teste falha.
assertTrue(i == 5);
assertFalse(boolean condição)
Verifica se a
condição é falsa.
Se for verdadeira, o
teste falha.
assertFalse(i == 5);
fail()
Faz o código falhar
incondicionalmente.
fail();
assertEquals(double esperado, 
 double obtido,
 double delta)
· 
Verifica se (obtido -
delta ≤
valorEsperado ≤
obtido + delta). Se
não for, o teste
falha.
assertEquals(i, 5, 0.001);
A lista completa de métodos de apoios está disponível em JUnit 4.12 API. Para usar esses métodos é necessário fazer:
*
Note que o import estático é um recurso do Java que permite que métodos e atributos com escopo de classe possam ser usados sem
colocar o nome da classe. Isso simplifica o código de teste, já que não é necessário escrever (), por exemplo, – é
possível escrever apenas ().
Considere uma classe , que faz operações matemáticas básicas com números inteiros. Para testá-la, criamos a classe 
 que faz, por enquanto, apenas um teste: .
Calculadora.java CalculadoraTeste.java
package br.univesp.gqs;
public class Calculadora {
 private int resultado;
 public int somar(int v1, int v2) {
 resultado = v1 + v2;
 return resultado;
 }
 public int dividir(int dividendo, int divisor) {
 if (divisor == 0)
 throw new ArithmeticException("Divisao por
 zero");
 resultado = dividendo / divisor;
 return resultado;
 }
 public int getUltimoResultado() {
 return resultado;
 }
}
package br.univesp.gqs;
 
import static org.junit.Assert.*;
import org.junit.Test;
public class CalculadoraTest {
 @Test
 public void somaComValoresPositivos() {
 Calculadora c = new Calculadora();
 assertTrue(c.somar(1, 1) == 2);
 }
}
https://junit.org/junit4/javadoc/latest/index.html
É muito comum que vários testes precisem fazer uma mesma inicialização. Para facilitar isso, o jUnit permite anotar um método com
@Before, indicando que aquele método será executado antes de cada método.
Para usar essa anotação é necessário fazer o import de . Por exemplo, no caso da calculadora, poderíamos fazer
um método para criar uma nova Calculadora antes de cada teste. Isso evitaria que a execução de um teste anterior altere o estado da
calculadora (no caso o valor do atributo resultado) e evitaria ter que repetir o código de criação em cada teste. Note que para isso é
necessário criar um atributo , o qual não é inicializado. Antes da execução de cada teste, o jUnit chama o método (já
que ele é anotado com @Before), criando um novo objeto. 
package br.univesp.gqs;
 
import static org.junit.Assert.*;
 
import org.junit.Before;
 import org.junit.Test;
 
public class CalculadoraTest {
 Calculadora c;
 
 @Before
 public void inicializacao() {
 c = new Calculadora();
 }
 
 @Test
 public void somaComValoresPositivos() {
 assertTrue(c.somar(1, 1) == 2);
 }
 
 @Test
 public void somaComValoresNegativos() {
 assertTrue(c.somar(-1, -1) == -2);
 }
 }
Note que caso o atributo fosse declarado:
Calculadora c = new Calculadora();
e não fosse colocado o método inicialização, só teríamos um objeto , que seria usado por todos os testes. Isso pode ser
um problema, já que o teste pode precisar de um objeto no seu estado inicial (a execução dos métodos durante o teste pode alterar o
estado do objeto).
Por fim, um outro recurso básico do jUnit é testar a ocorrência de uma exceção. Para fazer isso é necessário colocar um parâmetro na
anotação @Test, informando qual a classe da exceção, como no exemplo abaixo.
@Test(expected=ArithmeticException.class)
public void divisaoPorZero() {
 c.dividir(1, 0);
}
Note que não é necessário fazer uma asserção, já que o teste espera a ocorrência da exceção. Se a exceção não acontecer, o teste
falhará.
 
TESTANDO DEPENDÊNCIAS
A maior dificuldade ao fazer testes de unidade é lidar com dependências. Seguindo o princípio Isole a unidade sendo testada, temos que de
alguma forma impedir que uma outra classe gere falhas no teste da classe em questão. A forma de fazer isso é criando dublês de teste.
Vamos a um exemplo: imagine que agora a calculadora trabalhe com uma memória. Ao invés de os métodos receberem os dois operandos,
a calculadora usa o valor da memória como primeiro operando. Com isso, criamos as classes e 
(implementada como uma pilha).
CalculadoraComMemoria.java Memoria.java
package br.univesp.gqs;
 
public class CalculadoraComMemoria {
 private Memoria m = new Memoria();
 public void adicionar(int valor) {
 m.salvar(valor);
 }
 public int somar(int v) {
 if (m.estaVazia())
 throw new RuntimeException("Memoria
 vazia");
 int resultado = m.getUltimoValor() + v;
 m.salvar(resultado);
 return resultado;
 }
}
package br.univesp.gqs;
import java.util.ArrayDeque;
import java.util.Deque;
public class Memoria {
 private Deque<Integer> m =
 new ArrayDeque<Integer>();
 /**
 * Salva o valor na memoria.
 * @param valor O valor salvo.
 */
 public void salvar(int valor) {
 m.push(valor);
 }
 /**
 * Obtem o ultimo valor e o apaga da memoria.
 * @return O ultimo valor ou um
 *RuntimeException caso não haja valor na
 * memória.
 */
 public int getUltimoValor() {
 if (m.isEmpty())
 throw new RuntimeException("Vazia");
 return m.pop();
 }
 /**
 * Apaga todo o conteúdo da memoria.
 */
 public void resetar() {
 m.clear();
 }
 public boolean estaVazia() {
 return m.isEmpty();
 }
}
Essa mudança gera um problema para testar o método , como no exemplo abaixo: caso o método da
classe falhe, o método também falhará – mas não por culpa dele! Mas como fazer um teste sem depender dessa
implementação específica da classe ? 
package br.univesp.gqs;
import static org.junit.Assert.*;
import org.junit.Test;
public class CalculadoraComMemoriaTest {
 @Test
 public void somaComValoresPositivos() {
 CalculadoraComMemoria c = new CalculadoraComMemoria();
 c.adicionar(1);
 assertTrue(c.somar(1) == 2);
 }
}
A solução para esse problema é criarmos uma classe específica para o teste e fazer com que a 
 use essa quando estivermos testando. Note que a de teste não deve ter uma
lógica complexa: ela deve apenas se comportar como o esperado. Porém, por mais que a ideia seja simples, ela esbarra em dois
princípios: Mantenha a lógica de teste fora do código de produção e Não modifique o sistema para testar. Temos que encontrar uma forma
de evitar que a de teste seja colocada em produção e, pior, precisamos evitar mudanças na classe 
. Porém, sem mudar a classe será impossível isolar o teste! O problema é que a classe não foi
projetada para ser testável, não atendendo a esse princípio. Não tem como usar uma outra memória com a classe desse jeito!
Para tornar a classe testável, precisamos melhorar o design dela. Para isso usaremos o conceito de injeção de dependência[4]. Ao invés
de a classe criar a Memoria, fazemos com que alguma outra classe (por exemplo, a classe com o main)
diga à qual a implementação concreta de será usada. Ou seja, a dependência a uma 
será injetada na classe . A forma mais simples de fazer isso é criar um construtor para 
, o qual recebe a implementação de usada[5]. Note que o resto do código se manteve igual.
package br.univesp.gqs;
public class CalculadoraComMemoria {
 private Memoria m;
 public CalculadoraComMemoria(Memoria m) {
 this.m = m;
 }
 public void adicionar(int valor) {
 m.salvar(valor);
 }
 public int somar(int v) {
 if (m.estaVazia()) throw new RuntimeException("Memoria vazia");
 int resultado = m.getUltimoValor() + v;
 m.salvar(resultado);
 return resultado;
 }
}
Para testar agora, precisamos criar uma de teste. Essa nova classe precisa ser o mais simples possível, para não introduzir
defeitos, e ainda assim funcionar da forma esperada pela . A forma mais simples de fazer isso é criarum Stub. Segundo Fowler[6], Stubs “providenciam respostas pré configuradas para as chamadas feitas durante os testes, normalmente não
respondem a nada que não esteja programado para o teste”. Um Stub para a classe Memoria no teste de 
 é apresentado a seguir.
class MemoriaParaTeste extends Memoria {
 public void salvar(int valor) {
 }
 
 public int getUltimoValor() {
 return 1;
 }
 
 public void resetar() {
 }
 
 public boolean estaVazia() {
 return false;
 }
}
Note que a classe é extremamente simples e não faz nada além do esperado pelo teste em questão. O precisa
retornar 1? Então o método sempre retorna 1. O precisa retornar false? Então ok, ele sempre retornará false. Como o
método não é chamado, usamos uma implementação vazia – mas poderíamos até ignorá-lo na implementação e usar o da
classe pai.
Com isso podemos fazer o nosso teste independente da , ao injetar a 
package br.univesp.gqs;
 
import static org.junit.Assert.*;
 
import org.junit.Test;
 
public class CalculadoraComMemoriaTest {
 
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftn4
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftn5
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftn6
 @Test
 public void somaComValoresPositivos() {
 CalculadoraComMemoria c = new CalculadoraComMemoria(new MemoriaParaTeste());
 c.adicionar(1);
 assertTrue(c.somar(1) == 2);
 }
}
 Por mais que Stubs resolvam o problema, eles têm alguns pontos negativos:
O Java possui alguns recursos para diminuir o impacto do último ponto apresentado. Podemos colocar a classe de teste no mesmo arquivo
de teste (como uma classe privada) ou usar uma classe anônima. Um exemplo usando classe anônima é apresentado a seguir. Note que
ao criar a , já colocamos os métodos redefinidos, evitando criar uma nova classe.
package br.univesp.gqs;
 
import static org.junit.Assert.*;
 
import org.junit.Test;
 
public class CalculadoraComMemoriaTest {
 @Test
 public void somaComValoresPositivos() {
 CalculadoraComMemoria c = new CalculadoraComMemoria(new Memoria() {
 public void salvar(int valor) {
 }
 public int getUltimoValor() {
 return 1;
 }
 public void resetar() {
 }
 public boolean estaVazia() {
 return false;
 }
 });
 c.adicionar(1);
 assertTrue(c.somar(1) == 2);
 }
 }
Para lidar com os outros pontos negativos, é necessário colocar mais lógica no Stub ou então usar um outro tipo de dublê[7]: um Mock.
Existem diversas bibliotecas para Java para trabalhar com Mocks como, por exemplo, Mockito, EasyMock e JMock. Porém, nesta aula não
trabalharemos com Mock. Se você quiser saber mais sobre isso, veja uma dessas bibliotecas!
 
BOAS PRÁTICAS
Por fim, algumas boas práticas ao criar o teste de unidade.
Não garantem que os métodos sejam chamados do jeito certo. Caso o método possua um parâmetro,
o Stub não verifica se o parâmetro esperado foi passado. Além disso, o Stub não verifica se os métodos
foram chamados na sequência correta (no exemplo precisamos primeiro salvar um valor para chamar o 
).
Não verificam se um método não foi chamado. Muitas vezes se espera que um método da classe simulada
seja chamado (por exemplo, esperamos que o seja chamado). Em alguns casos ele
pode ter que ser chamado um número fixo de vezes. Porém, o Stub não verifica isso!
É preciso criar uma nova classe para cada teste. Isso pode tornar o código de teste desnecessariamente
grande, já que para cada teste será necessário criar um novo Stub.
Coloque valores diretamente na asserção. Prefira calcular manualmente o valor a ser verificado,
colocando-o diretamente na asserção. Isso é importante pois os desenvolvedores têm a tendência de copiar
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftn7
 
REFERÊNCIAS 
DELAMARO, M.E.; MALDONADO, J.C.; JINO, M (Org.).Introdução ao Teste de Software. 2 ed. Pearson, 2016.
MESZAROS, G. xUnit Test Patterns: Refactoring Test Code. Addison-Wesley, 2007.
 
Notas de Rodapé
[1] Um problema a considerar quando o desenvolvedor é responsável por apenas testes intramétodos é a dificuldade em testar um
método isoladamente. Para testar um método qualquer,no mínimo será necessário chamar o construtor da classe – que é um outro
método. Mais que isso, muitas vezes é preciso chamar um método de acesso para saber se o resultado da chamada do método
testado teve o efeito esperado.
[2] Netbeans: https://netbeans.org/kb/docs/java/junit-intro_pt_BR.html.
 Eclipse: https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-junit.htm.
 IntelliJ: https://www.jetbrains.com/help/idea/configuring-testing-libraries.html.
[3] Por mais que pareça mais elegante em português, o problema dessa convenção é a dificuldade para
encontrar o arquivo – como todos começam com Testa, para procurar um arquivo você sempre tem que ignorar esse prefixo. 
[4] Veja mais detalhes em <http://javafree.uol.com.br/artigo/871453/Inversion-Of-Control-Containers-de-Inversao-de-Controle-e-o-
padrao-Dependency-Injection.html>.
[5] Como só temos um tipo de Memoria, não criei uma interface Memoria – o que seria o mais natural em uma implementação da
injeção de dependência.
[6] https://www.infoq.com/br/articles/mocks-Arent-Stubs
[7] www.infoq.com/br/articles/mocks-Arent-Stubs
a fórmula que está no código a ser testado. Se ela estiver incorreta, o teste também estará incorreto. Ao
fazer a conta manualmente, o desenvolvedor tem a oportunidade de encontrar o defeito ao aplicar a
fórmula.
Faça testes para encontrar defeitos e não para passar. Em empresas em que há uma política de testes,
é comum desenvolvedores criarem testes só para atender as restrições impostas (por exemplo, 80% de
cobertura), mas que não verificam nada. Isso obviamente é um desperdício!
Não use valores aleatórios. Valores aleatórios dificultam a reprodução de uma falha – ela pode acontecer
com apenas alguns valores específicos que podem ser gerados raramente. Com isso, o teste pode ter um
comportamento inconsistente, falhando aleatoriamente. Isso dificulta o teste e a depuração, além de
confundir quem está testando!
Considere os conceitos de teste estrutural e funcional. A prática atual sugere que se faça tanto testes
estruturais quanto funcionais ao criar a suíte de testes de unidade para uma classe. Os testes estruturais
darão a cobertura; os testes funcionais darão casos interessantes (e ajudarão a encontrar problemas na
especificação da classe). Se você usar Test-Driven Development (TDD), é fundamental misturar os dois!
Não teste métodos triviais. Como não é viável testar tudo, temos que escolher quais são os testes que
terão a maior chance de encontrar defeitos. Um método trivial, por exemplo, um simples getter, tem baixa
chance de defeito já que ele não faz nada além de retornar um valor definido de outra forma. Então não vale
a pena testa-lo. O interessante é que esses métodos muitas vezes fazem parte de um outro teste (por
exemplo, para saber se um método complexo fez o pretendido, é preciso chamar um getter), portanto eles
são executados (e cobertos) durante os testes.
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftnref1
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftnref2
https://netbeans.org/kb/docs/java/junit-intro_pt_BR.html
https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-junit.htm
https://www.jetbrains.com/help/idea/configuring-testing-libraries.html
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftnref3https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftnref4
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftnref5
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftnref6
https://ava.univesp.br/bbcswebdav/pid-497665-dt-content-rid-1951270_1/courses/EES201-2021S1B2C1-T002/2021.2B/SEMANA4-texto-base1.html#_ftnref7