#Este é um post fechado Este post está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!
dê seu feedback
post favorito
Artigo .net magazine 69 - TDD
Test-Driven Development na prática
.net Magazine 69
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 69
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 69
BRK##: 0 - 0
Boas Práticas – Engenharia de Software – Tutorial
TDD
Test-Driven Development na prática
Do que trata o artigo
O artigo mostra de forma prática o desenvolvimento de software utilizando Test-Driven Development (desenvolvimento guiado por testes).
Para que serve
Conhecer a prática de Test-Driven Development e entender como aplicá-la em cenários reais do dia-a-dia do desenvolvimento de software, entendendo quais os benefícios existentes em sua adoção e o por que ela nos proporciona fazer software para durar.
Em que situação o tema é útil
Test-Driven Development está relacionado com a escrita de código claro, limpo, de qualidade e feito para durar. Através dele podemos manter um registro de tudo o que nosso sistema é capaz de fazer, e desta forma conseguimos garantir que implementações e alterações futuras não quebrem o que já existe. Além disso, o TDD nos proporciona escrever código menos acoplado nos ajudando a garantir um melhor design de nossas classes e camadas, além de manter uma documentação executável de tudo que está contido em nosso sistema.
Resumo do DevMan
O Test-Driven Development já não é mais uma prática nova. Tendo sido oficialmente chamada de Test-Driven em meados de 2002, esta prática nos ensina a primeiro escrever testes para o nosso código para só depois escrever o código e, por fim, arrumá-lo para que fique mais claro e limpo. Este tipo de prática nos leva a ersos benefícios, como a obtenção de um melhor design, melhor entendimento e conhecimento do negócio, especificações mais claras e outros que serão abordados de forma prática neste artigo.
Talvez o Test-Driven Development venha sendo praticado há muitos anos por algumas pessoas, mas de fato o mesmo começou a se popularizar em meados de 2002, com a publicação do livro “Test-Driven Development by Example”, do autor Kent Beck. A grande promessa de Kent Beck no início do livro é a de conseguirmos produzir “clean code that works”, ou seja, “código limpo que funciona”.
De uma forma simples Kent Beck explica que o Test-Driven Development (que a partir de agora chamaremos só de TDD) é uma prática que possibilita ao desenvolvedor obter feedback de forma muito rápida sobre o código sendo escrito. É possível entender em poucos segundos o que está acontecendo e desta forma é possível aprender tudo o que o código pode nos ensinar. E se estamos obtendo feedback do código de forma rápida e aprendendo com o mesmo, podemos assim produzir um código limpo.
O TDD possui um mantra básico que irá nos guiar: Red/Green/Refactor. Primeiro escreva um teste. Este deve ser um teste que falhe e assim obteremos um red (uma falha no teste). Escreva então o código necessário para o teste passar. Neste ponto é permitido escrever qualquer tipo de código para que o teste passe e então obteremos um verde (um teste que funciona). Remova então todas as duplicações de código, e limpe-o, fazendo assim um refactoring.
Nota do DevMan
Refactoring é uma técnica utilizada para alterar a estrutura interna de um trecho de código sem alterar o comportamento existente. Cada uma destas transformações é chamada de refactoring. Para obter mais informações sobre refactoring visite a “Refactoring Home Page”, mantida por Martin Fowler (confira o endereço na seção de links ao final do artigo).
A ideia de escrever testes antes de escrever o código em si pode parecer estranha à primeira vista, no entanto ela é muito válida. Quando escrevemos um teste antes do código estamos pensando exatamente em como queremos que nosso código seja e como queremos que ele se comporte. Estamos desenvolvendo sob o ponto de vista de quem consome o nosso código, e desta forma escrevemos um código mais simples e claro. Este é um dos grandes benefícios do TDD – auxiliar e orientar o design da aplicação.
ATENÇÃO! A exibição deste artigo foi interrompida.
#Este é um post fechado
Este post está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!
Boas Práticas – Engenharia de Software – Tutorial
TDD
Test-Driven Development na prática
Do que trata o artigo
O artigo mostra de forma prática o desenvolvimento de software utilizando Test-Driven Development (desenvolvimento guiado por testes).
Para que serve
Conhecer a prática de Test-Driven Development e entender como aplicá-la em cenários reais do dia-a-dia do desenvolvimento de software, entendendo quais os benefícios existentes em sua adoção e o por que ela nos proporciona fazer software para durar.
Em que situação o tema é útil
Test-Driven Development está relacionado com a escrita de código claro, limpo, de qualidade e feito para durar. Através dele podemos manter um registro de tudo o que nosso sistema é capaz de fazer, e desta forma conseguimos garantir que implementações e alterações futuras não quebrem o que já existe. Além disso, o TDD nos proporciona escrever código menos acoplado nos ajudando a garantir um melhor design de nossas classes e camadas, além de manter uma documentação executável de tudo que está contido em nosso sistema.
Resumo do DevMan
O Test-Driven Development já não é mais uma prática nova. Tendo sido oficialmente chamada de Test-Driven em meados de 2002, esta prática nos ensina a primeiro escrever testes para o nosso código para só depois escrever o código e, por fim, arrumá-lo para que fique mais claro e limpo. Este tipo de prática nos leva a ersos benefícios, como a obtenção de um melhor design, melhor entendimento e conhecimento do negócio, especificações mais claras e outros que serão abordados de forma prática neste artigo.
Talvez o Test-Driven Development venha sendo praticado há muitos anos por algumas pessoas, mas de fato o mesmo começou a se popularizar em meados de 2002, com a publicação do livro “Test-Driven Development by Example”, do autor Kent Beck. A grande promessa de Kent Beck no início do livro é a de conseguirmos produzir “clean code that works”, ou seja, “código limpo que funciona”.
De uma forma simples Kent Beck explica que o Test-Driven Development (que a partir de agora chamaremos só de TDD) é uma prática que possibilita ao desenvolvedor obter feedback de forma muito rápida sobre o código sendo escrito. É possível entender em poucos segundos o que está acontecendo e desta forma é possível aprender tudo o que o código pode nos ensinar. E se estamos obtendo feedback do código de forma rápida e aprendendo com o mesmo, podemos assim produzir um código limpo.
O TDD possui um mantra básico que irá nos guiar: Red/Green/Refactor. Primeiro escreva um teste. Este deve ser um teste que falhe e assim obteremos um red (uma falha no teste). Escreva então o código necessário para o teste passar. Neste ponto é permitido escrever qualquer tipo de código para que o teste passe e então obteremos um verde (um teste que funciona). Remova então todas as duplicações de código, e limpe-o, fazendo assim um refactoring.
Nota do DevMan
Refactoring é uma técnica utilizada para alterar a estrutura interna de um trecho de código sem alterar o comportamento existente. Cada uma destas transformações é chamada de refactoring. Para obter mais informações sobre refactoring visite a “Refactoring Home Page”, mantida por Martin Fowler (confira o endereço na seção de links ao final do artigo).
A ideia de escrever testes antes de escrever o código em si pode parecer estranha à primeira vista, no entanto ela é muito válida. Quando escrevemos um teste antes do código estamos pensando exatamente em como queremos que nosso código seja e como queremos que ele se comporte. Estamos desenvolvendo sob o ponto de vista de quem consome o nosso código, e desta forma escrevemos um código mais simples e claro. Este é um dos grandes benefícios do TDD – auxiliar e orientar o design da aplicação.
ATENÇÃO! A exibição deste artigo foi interrompida.
#Este é um post fechado Este post está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!
1 COMENTÁRIO
Você está em:
canal .net
Publicidade
Estudo comparativo entre banco de dados IBM Informix e Microsoft SQL
Vinicius Quaiato
Space do autor
Trabalha com desenvolvimento de software há cerca de 4 anos, especificamente com tecnologias Microsoft .NET. Aficcionado por arquitetura e boas práticas. Atualmente trabalha com desenvolvimento e arquitetura de aplicações SOA. Atua na comunidade .Net Architects e coordena o grupo de Coding Dojo da m...
Space do autor
0
0
Conheça os planos de créditos DevMedia e visualize esse post agora mesmo!