Olá pessoal estou fazendo meu trabalho de conclusão de curso sobre TDD, e gostaria de algumas sugestões para exemplificar o uso de TDD.
Gostaria de algo que fosse simples de desenvolver, pq não sou mt boa em programação.
Se puderem me ajudar. Obrigada
TDD nada mais são do que Teste De Desenvolvedor
Quando você faz teste que não foi criado pela equipe de qualidade do produto, você está fazendo um teste extra, que é o teste de desenvolvedor.
[quote=marcio_gs]TDD nada mais são do que Teste De Desenvolvedor
Quando você faz teste que não foi criado pela equipe de qualidade do produto, você está fazendo um teste extra, que é o teste de desenvolvedor.[/quote]
Vc tá zuando né?
[quote=marcio_gs]TDD nada mais são do que Teste De Desenvolvedor
Quando você faz teste que não foi criado pela equipe de qualidade do produto, você está fazendo um teste extra, que é o teste de desenvolvedor.[/quote]
Marcio,
TDD é:
crie um teste unitário que espera um determinado comportamento de uma classe,
verifique que esse teste falha,
crie o código para atender a expectativa do teste,
refatore o código e o teste,
repita o ciclo.
TDD não é o teste, é o processo.
Hmm, se o seu forte nao é programação acho que você não escolheu o melhor dos temas para seu TCC. TDD é bastante dificil, mesmo para programadores experientes. Voce le, le, le e a ficha demora pra cair, pra muitos nao cai nunca.
Mas já que começou, agora vai em frente, só que vai ter que suar a camisa.
Eu recomendo, muitissimo, que voce va beber direto na fonte.
Mas TDD é justamente sobre programação. Posso estar errado, mas acredito que você tenha escolhido o tema porque gosta de escrever casos de teste e procurar bugs em códigos finalizados, e talvez tenha imaginado que TDD fosse justamente isso, o que é um engano.
Test Driven Development, ou seja, Desenvolvimento Dirigido por Testes. O TDD é uma forma previsível de desenvolver. Voce sabe quando acabou sem ter de se preocupar com uma longa trilha de erros.
O exemplo acima é bem simples e BEM errado!! Em TDD, não criamos uma classe e depois os testes. É justamente o OPOSTO. Criamos um teste e DEPOIS codificamos o que for essencial para esse teste passar. O desenvolvimento é GUIADO pelos testes, ou seja, o teste precisa existir ANTES do código.
Então BONZÃO posta um exemplo ai para nos ensinar.
Pois o que eu vi vc colocar foi uma critica e cade a solução ???
Aqui nesse forum vc lida com pessoas que tem suas duvidas expostas, e ainda bem que tem pessoas que ainda tentam ajudar. Diferente de Animais como sua raça mediocre que só pensa em criticar a boa intensão das pessoas.
Aprenda primeiro a lidar com gente para depois responder de maneira civilizada.
Então BONZÃO posta um exemplo ai para nos ensinar.
Pois o que eu vi vc colocar foi uma critica e cade a solução ???
Aqui nesse forum vc lida com pessoas que tem suas duvidas expostas, e ainda bem que tem pessoas que ainda tentam ajudar. Diferente de Animais como sua raça mediocre que só pensa em criticar a boa intensão das pessoas.
Aprenda primeiro a lidar com gente para depois responder de maneira civilizada. [/quote]
Calma aí pessoal, não vamos faltar com respeito…
Na verdade, vc criou seues testes unitários, mas o que o TDD prega, é que os testes sejam realizados antes da estrutura e lógica das classes, até para facilitar o desacoplamento de código posteriormente.
Então BONZÃO posta um exemplo ai para nos ensinar.
Pois o que eu vi vc colocar foi uma critica e cade a solução ???
Aqui nesse forum vc lida com pessoas que tem suas duvidas expostas, e ainda bem que tem pessoas que ainda tentam ajudar. Diferente de Animais como sua raça mediocre que só pensa em criticar a boa intensão das pessoas.
Aprenda primeiro a lidar com gente para depois responder de maneira civilizada. [/quote]
Ele nao esta criticando sua boa intencao, ele esta criticando a sua abordagem. Talvez ele nao tenha feito de uma forma muito polida, mas tambem nao foi nenhuma agressao para voce reagir dessa forma.
E quando voce expoe publicamente sua opiniao está sim sujeito a criticas.
Sobre a opiniao do esmirralha sobre o seu post, concordo plenamente. Sua abordagem está sim equivocada. Em TDD escrevemos antes os testes, depois implementamos alguma coisa pra ele.
Eu sei que voce fez com a intencao de ajudar, mas as vezes acaba confundindo quem ta começando.
Olá Nayara,
Vou tentar exemplificar o processo de forma prática.
Então vou criar um cenário simples e aplicar o TDD para resolver meu probleminha.
Tarefa: Criar um cadastro de cliente com validação do CPF. De acordo com a fórmula.
Fórmula de validação do CPF:
http://www.gerardocumentos.com.br/?pg=entenda-a-formula-do-cpf3
Pensando na minha tarefa acima, imaginei que terei que criar uma classe chamada CPFValidator com um metodo chamado “validate” que irá receber o número do CPF como parâmetro e retornar um boolean dizendo se meu CPF está válido ou não.
Nesse momento eu acabei de especificar o contrato ao qual eu quero testar.
Modelo rabiscado:
Baseado nisso eu inicio meu desenvolvimento criando o teste unitário.
Segue exemplo:
public class CPFValidatorTest {
@Test
public void testValidateCPF() {
// Cpf Valido
final String cpfNumber = "70984958754";
// Nesse ponto do teste ele irá reclamar de que a classe não existe.
// Entao terei que criar minha classe.
CPFValidator cpfValidator = new CPFValidator();
// Se o metodo não existe devo criá-lo também!
boolean result = cpfValidator.validate(cpfNumber);
// Como o cpfNumber que eu passei tem uma formatação correta
// O resultado deve ser válido
assertEquals("Caso 1 - CPF Valido.", true, result);
}
}Nesse momento, eu tenho apenas meu teste e o esqueleto não implementado da minha classe CPFValidator.
Apesar de não existir ainda a implementação da classe eu acabei modelando e criando um mecanismo de como testar o comportamento que minha implementação irá ter.
Sendo assim meu desenvolvimento est’a guiado pelo caso de teste que eu criei (TDD).
Seguindo o processo os próximos passos seriam: (De acordo coma a figura do amigo ali).
- Criar implementação inicial do método valiedate.
- Adicionar novos casos de testes a minha classe de testes
- Refatorar o metodo validate se preciso.
Simplificando muito é isso…
Edorso tudo que o amigo YvGa disse, TDD parece simples, mas exige muita prática e disciplina do programador.
Ao meu ver é o estilo de Design que mais exige que a pessoa saiba programar bem.
[quote=nayaracf]Olá pessoal estou fazendo meu trabalho de conclusão de curso sobre TDD, e gostaria de algumas sugestões para exemplificar o uso de TDD.
Gostaria de algo que fosse simples de desenvolver, pq não sou mt boa em programação.
Se puderem me ajudar. Obrigada[/quote]
Olá, naya.
Fizemos na empresa um exercicio simples usando um supermercado, um de meus amigos colocou no blog dele http://resumotecnico.blogspot.com/ , esta em TDD na pratica; (os creditos são dele rsrs)
Foi um exercicio simples mais ajudou muito a galera, fomos incrementando os testes por parte by tio jack, sem esquecer das regrinhas red, green, refactoring e baby steps.
O que mais ajuda na minha opinião e eh o principio de tudo é você entender o problema antes de querer implementa-lo, parece simples mas ja vi gente se enroscar com isso.
Abraços.
[edit] desculpe a pelo atraso a essa hora você ja entregou seu tcc, mas fica a dica.
[quote=marcio_gs]TDD nada mais são do que Teste De Desenvolvedor
Quando você faz teste que não foi criado pela equipe de qualidade do produto, você está fazendo um teste extra, que é o teste de desenvolvedor.[/quote]
:shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock:
[quote=raf4ever][quote=marcio_gs]TDD nada mais são do que Teste De Desenvolvedor
Quando você faz teste que não foi criado pela equipe de qualidade do produto, você está fazendo um teste extra, que é o teste de desenvolvedor.[/quote]
:shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: [/quote]
Brabo é o cara falar uma bobagem dessa e nem pelo menos corrigir ou excluir o post…
Resumidamente, o ato/tecnica de se “testar antes” significa escrever primeiro seu codigo de teste, antes mesmo do código funcional existir. Ir aprimorando (refatorando) este código até chegar a um ponto aceitável (teste passando, design compreensível, codigo otimizado) - a vantagem disso é que se tem um feedback muito rapido do seu proprio codigo para contigo, influenciando MUITO no design, visto que seu código já nasce testável (logo, com uma API mais acessível a seus usuários, pois o primeiro usuário dela foi você 
).