Oi a todos. Estou estudando sobre TDD, e achei um artigo muito interessante na javamagazine sobre testes de software, TDD, porém fiquei totalmente confusa agora.
Aqui está basicamente o fluxo que foi colocado para os testes a serem realizados.
Independente de no modelo acima estar contemplando fases do modelo tradicional, fiquei com dúvidas.
Minhas dúvidas que não são poucas, começam por aqui:
Como fazer teste de carga e estresse na prática apenas com requisitos???
Pra mim, isso seria depois de um módulo, ou alguma parte pronta, você começa a fazer um teste desse pra ver o comportamento, se o sistema vai aguentar várias requisições, vários usários, etc. Como seria feito isso na prática sem nenhum código??? Estou errada?
Como fazer testes funcionais apenas com protótipos???
No meu entendimento, teste funcional o sistema já deve ter alguma tela pronta, ou usando um framework para fazer isso simulando usuários, depois de ter feito teste de unidade e o teste de sistema e aí sim fazer um teste funcional. Estou errada?
Teste de sistema antes do teste de unidade???
Pelo pouco que estudei até agora, eu achava que primeiro fazia teste em unidades pequenas e separadas, e aí sim depois disso seria feito o teste de sistema, onde envolveria varias unidades que foram testadas, mas agora sendo testadas num conjunto maior, digamos essas unidades integradas. Estou errada ?
Quem tiver uma conhecimento prático sobre desenvolvimento utilizando prática de testes, me auxilie nas minhas dúvidas.
Nao, voce precisa fazer/executar testes funcionais desde o inicio, nao com prototipos mas sim com os requisitos. O ideal seria nao incluir a UI nos testes funcionais. O objetivo é testar as regras de negocio. Num projeto bem arquitetado essas regras de negocio estao agrupadas num lugar, e este lugar nao é a interface do usuario. Quando os testes funcionais passarem significa que o caso de uso foi implementado.
Voce esta falando dos testes de integracao? Se for acho que voce esta certa.
Obrigada pelas respostas, nesse aspecto acima que você disse, então no caso seria realizado após os testes de unidade?
Porque você disse que ao passar por esse teste, então o caso de uso foi implementado, então seguindo uma lógica, após testar as unidades, e ai verificar se as regras estão atendendo?
[quote=carol_programadora]Oi a todos. Estou estudando sobre TDD, e achei um artigo muito interessante na javamagazine sobre testes de software, TDD, porém fiquei totalmente confusa agora.
Aqui está basicamente o fluxo que foi colocado para os testes a serem realizados.
…
Independente de no modelo acima estar contemplando fases do modelo tradicional, fiquei com dúvidas.
Minhas dúvidas que não são poucas, começam por aqui:
[/quote]
Carol:
O que a figura mostra é apenas uma classificação tradicionalíssima de tipos de testes no contexto de um
processo em cascata, processo este que já foi mais malhado que o Judas na semana santa
(não li o artigo, estou me baseando apenas na figura).
Testes não deveriam acontecer em fases: são atividades complementares ao
desenvolvimento e devem ser escritos e executados em paralelo a outras atividades,
procurando que eles comecem a acontecer o mais cedo possível.
TDD = “Desenvolvimento guiado pelos testes” é algo muito diferente a esse fluxo, e tem muito mais a ver com
a geração de especificações com exemplos de uso executáveis mecanicamente. Basicamente, significa que
antes de gerar um artefato, vc cria um criterio para verificar automaticamente a corretude desse artefato:
o teste sempre vem antes, e para teste unitário, logo antes.
Supondo que a definição de “fazer” seja executar um teste automatizado, é verdade que vc precisa ter algo executável pronto.
A especificação pode ser feita cedo, e o “pronto” pode ser apenas uma casca para poder executar o teste. É mais saudável que
os requisitos de desempenho sejam documentados através de uma especificação automatizada, que enterrados dentro de um
arquivo do Word.
O teste de desempenho passa a evoluir junto com o restante das atividades de desenvolvimento. Isto baliza decisões de
arquitetura e design mais cedo que tarde.
Teste funcional pode ser entendido de várias formas. Pelo contexto, a figura se refere a testes que utilizam a interface usuário.
Me preocupa o discurso de fazer isso, depois aquilo, e depois aquilo outro. O que acontece, no caso de interfaces web, é que as
pessoas se acostumaram a testar com a interface já pronta, usando ferramentas que gravam as ações do usuário em um script que
funciona como regressão.
O protótipo, entendido como uma primeira iteração da interface usuário, pode ser algo muito simplificado, apenas com uma interface
pobre que permita especificar o fluxo das interações do usuário, e gerar roteiros de teste a partir disso. Existe, por exemplo, uma
ferramenta chamada CubicTest, que permite especificar um fluxo testável para uma aplicação web através de um grafo.
Faço a ressalva que é muito comum cair na armadilha de investir de maneira desproporcional em testes de interface usuário, que são mais
caros e frágeis que outros tipos.
Em termos. Como tudo em testes, as definições são nebulosas. Se consideramos teste de sistema como algo ponta-a-ponta, podemos
ter um primeiro teste apenas com as pontas. A montagem da infraestrutura para poder testar um sistema deve ser feita bem no início,
e os outros testes se encaixam dentro dessa infraestrutura. O ciclo dos testes unitários se confunde com o ciclo de desenvolvimento.
Lembrando, testes são atividades feitas em paralelo às outras. O “antes” e “depois” não devem se referir a todos os testes de tal tipo antes
de todos os testes de tal outro tipo.
Uma coisa que existe no TDD é escrever testes primeiro, depois o código. Naturalmente o teste falhará pois não há nada escrito. Todo o objetivo do TDD é fazer esses testes passarem. Isso é chamado de red green refactoring.
Outro motivo para esses testes de mais alto nível é ter em mente que o sistema deve passar neles algum dia (ex: aguentar 1000 usuarios concorrentes por minuto). Se for pra se preocupar com a carga por último, provavelmente terá que refazer o sistema.
[quote=Bruno Laturner]Uma coisa que existe no TDD é escrever testes primeiro, depois o código. Naturalmente o teste falhará pois não há nada escrito. Todo o objetivo do TDD é fazer esses testes passarem. Isso é chamado de red green refactoring.
.[/quote]
complementando:
Escrever o código para os testes antes de criar as classes, metodos, etc. propriamente ditos, também ajuda a abrir a mente. []s
[quote=carol_programadora][quote=cmoscoso ]
Nao, voce precisa fazer/executar testes funcionais desde o inicio, nao com prototipos mas sim com os requisitos. O ideal seria nao incluir a UI nos testes funcionais. O objetivo é testar as regras de negocio. Num projeto bem arquitetado essas regras de negocio estao agrupadas num lugar, e este lugar nao é a interface do usuario. Quando os testes funcionais passarem significa que o caso de uso foi implementado.
[/quote]
Obrigada pelas respostas, nesse aspecto acima que você disse, então no caso seria realizado após os testes de unidade?
Porque você disse que ao passar por esse teste, então o caso de uso foi implementado, então seguindo uma lógica, após testar as unidades, e ai verificar se as regras estão atendendo?
fiquei confusa em ponto exato realizar :roll: [/quote]
O que voce entende por “realizar” um teste? Se eu entendi bem e voce quer dizer “executar”, entao eu executo os meus de 2 em 2 horas.
Testes funcionais (que sao escritos para/por analista de negocios no inicio) permitem saber quando uma determinada regra de negocio foi implementada. O teste funcional é a especificacao das regras numa forma que seja compreensivel para o seu analista do negocio ao mesmo tempo executavel. Testes de unidade sao testes do desevolvedor num nivel mais baixo, de implementacao.
Dito isso, a ordem em que eles sao “realizados” sao independentes uma vez que cada teste tem propositos diferentes. Na hora que passou o funcional é porque aquele caso de uso esta implementado (pelo menos como fora especificado pelo teste, por isso a importancia de ser escrito pelo analista).
