Revista .net Magazine 86

Elaborada basicamente por Kent Beck e formalizada no livro “Test-Driven Development – By Example”, o TDD não é uma metodologia de testes, mas sim, de desenvolvimento de software que pode ser facilmente integrada a outras delas, como o tão conhecido XP. O TDD, além de dar a garantia de que não haverá bugs, ajuda, por exemplo, a saber quais serão as próximas 10 linhas de código a serem escritas. Os testes guiarão o desenvolvimento dizendo exatamente o que deve ser codificado. Isso muda toda a maneira tradicional de escrever código. Você consegue se imaginar escrevendo um teste para algo que ainda não foi codificado? Por mais que isso pareça estranho, esse é um dos pilares da metodologia. No caso do TDD, em vez de utilizarmos documentos escritos para modelagem e especificação da estrutura interna de um software, utilizaremos testes unitários. O maior objetivo do Test-Driven Development, segundo Ron Jeffries, é o Clean Code That Works (código limpo e funcional). Se temos uma camada de testes garantindo que nada será quebrado, temos também total segurança para melhorar o design do código, algo que é feito com muita frequência no TDD. Assim, além do programa estar sem erros para o cliente, também estará muito bom para nós, porque o código estará limpo e fácil de se compreender. Testar antes de codificar: essa é a lei da XP! Como? Vamos a uma metáfora: como você faria para ter certeza que acertará “na mosca” toda vez que lançar uma flecha? Fácil: lance a flecha em algum lugar (uma árvore, por exemplo) e pinte as marcas do alvo em volta do ponto onde a flecha cravou. É uma boa analogia com o TDD. Outro tema intimamente relacionado aos Testes Unitários é o Refactoring. XP pede, entre outras coisas, que cada módulo seja testado antes de ser escrito. Isso implica na criação de classes de teste, cuja função é criar objetos de outra(s) classe(s), chamar seus métodos e verificar os resultados, declarando sucesso ou falha em cada teste. As práticas de refactoring e testes unitários ajudam bastante as equipes de desenvolvimento a melhorar a qualidade do código produzido, tanto no quesito estrutural (sintático) quanto no comportamental (semântico), respectivamente. Os testes unitários permitem que os resultados esperados sejam especificados mesmo antes da codificação dos métodos reais. Isso ajuda tanto a desenvolver o código dos métodos, quanto na verificação da qualidade das alterações nesses métodos. Antes de promover um código para a versão oficial, deve-se rodar todos os testes a ele pertinentes, garantindo 100% de sucesso. Os testes unitários procuram garantir que o refactoring realmente não altere o comportamento externo dos métodos. Refactoring e Testes unitários são os temas principais desta edição a .NET Magazine.

Boa leitura!

Sumário

iTextSharp
PDF no .NET
Francisco Gonzales Gonzalez

Vamos aprender XNA?
Entenda as facilidades proporcionadas pelo Framework para desenvolvimento de games da Microsoft
Elemar Júnior

Conversão de List para DataTable
Explorando Reflection para criar uma DataTable baseada em uma lista genérica
Vladimir Rech

VÍDEO - Veja nesta vídeo-aula como usar Reflection para inspecionar metadados de um assembly, como módulos, tipos e membros
Guinther Pauli

NHibernate
Conheça os recursos de Cascade
Rodrigo Sendin

WCF
Integração com o NHibernate
Rodrigo Sendin

VÍDEO - Veja nesta vídeo-aula como integrar o Windows Communication Foundation com o ADO.NET Entity Framework
Guinther Pauli

Veja nesta vídeo-aula como trabalhar com Navigation Properties e Lazy Loading no ADO.NET Entity Framework
Guinther Pauli

Test Driven Development
Garantindo a qualidade do software através de um código protegido por testes
Everton Lucas

VÍDEO – Veja nesta vídeo-aula como implementar práticas de TDD - Test Driven Development com Unit Tests e Code Coverage no Visual Studio 2010
Guinther Pauli

System.AddIn
Adicione extensibilidade ao seu software com arquitetura baseada em Add-In
Carlos Eduardo de Souza

Revista ClubeDelphi 130

Esta edição destaca o acesso a dados no Delphi Prism. Só para se ter uma ideia, existem dezenas de formas de acesso a dados no .NET Framework, motivo que causa muita confusão, principalmente para quem está iniciando na plataforma. Entre as formas de acesso, podemos citar o uso de ADO.NET através de classes como SqlConnection e SqlCommand (no caso do SQL Server), ou ainda usar o ADO.NET em uma camada separada, como um Data Access Layer, usando boas práticas e separação de responsabilidades, isolando o domínio. DataSets tipados e TableAdapters também são uma boa forma de acesso a dados, pois permitem separar o acesso em um layer independente da UI. Usando o ASP.NET temos o modelo baseado em DataSource, que tira proveito do mecanismo de DataBinding, incluindo o SqlDataSource e ObjectDataSource. Para um desenvolvimento mais profissional e orientado a objetos, podemos usar um framework como o NHibernate ou o ADO.NET Entity Framework.
O ADO.NET Entity Framework (EF) é a ferramenta de persistência e mapeamento objeto / relacional nativa do .NET Framework, concorrente direto do NHibernate. Ele originalmente apareceu pela primeira vez no Service Pack 1 do Visual Studio 2008 / .NET 3.5. No Visual Studio 2010 / .NET 4.0 ele está na sua versão 2, apesar de normalmente nos referenciarmos a ele por EF4 (versão 4). O ADO.NET EF permite o desenvolvimento de aplicações para .NET onde o foco principal é a orientação a objetos, sem uma comunicação direta com um servidor de banco de dados relacional, como o SQL Server. É o framework que gera todos os comandos SQL. A última versão permite que o desenvolvedor inicie a criação de um aplicativo pela definição do domínio (entidades), com um diagrama de classes, podendo a seguir gerar todo o esquema para o SGBDR. Essa técnica é conhecida como Model First Development. Se já possui um banco existente, o EF pode fazer a engenharia reversa, gerando entidades no modelo a partir do BD. Outra característica interessante do EF é a capacidade de suportar tipos complexos, uma novidade da última versão, bem como Lazy Loading, que permite o carregamento de entidades relacionadas conforme utilização. O que considero um dos melhores recursos é o novo suporte a POCO (Plain Old CLR Objects), onde podemos modelar o domínio da aplicação, com as entidades, sem gerar código que esteja atrelado ao framework ou a uma tecnologia em específico. As classes do domínio simplesmente mapeiam a tabela do banco, normalmente sem conter métodos ou derivar de uma classe base para que possam funcionar. Isso dá uma maior flexibilidade e independência ao se trabalhar com o EF. Isso é importante para aplicações em camadas, que prezam por baixo acoplamento entre suas partes, seguindo bons princípios do DDD (Domain Driven Design). Nesta edição, damos especial destaque ao uso dessa poderosa ferramenta para acesso a dados, utilizando o Delphi Prism XE.

Boa leitura!

Sumário

Delphi
Utilidades e Novidades
Paulo Quicoli

Delphi Prism
Melhorias da linguagem – Parte 4
Rodrigo Araujo

VÍDEO - Veja nesta vídeo aula como usar expressões Lambda no Delphi Prism
Guinther Pauli

Delphi Prism
Entendendo o que são Assemblies, Class Libraries e GAC
Guinther Pauli

dbExpress
Transações
Jéfferson Ricardo Zuchi

DataSnap XE
Técnicas avançadas
Alexandre José Gonçalves da Silva

Padrões Criacionais
Fabrique famílias de objetos
Rafael Stavarengo

Acesso a dados no Delphi Prism
Mapeamento Objeto / Relacional e Persistência com ADO.NET Entity Framework
Rodrigo Araujo

VÍDEO - Veja nesta vídeo aula como fazer utilizar o conceito de Model First com ADO.NET Entity Framework e Delphi Prism
Guinther Pauli


VÍDEO - Veja nesta vídeo aula como usar Linq To Entities com Delphi Prism”
Guinther Pauli

Delphi com PostgreSQL
Descobrindo o poder do elefante
Alexandre José Gonçalves da Silva