É um anti pattern transportar domínio rico.
Olá.
Existe um grande equívoco pairando no mercado a respeito de Arquitetura de Software e o Papel do Arquiteto de Software em uma equipe de desenvolvimento.
Alguns destes equívocos são baseados no mal-entendimento de alguns conceitos, outros baseados em mal-conceitos (ou má-padronização) de alguns entendimentos (se é que é certo falar assim). Mesmo entre os grandes arquitetos da comunidade, existem algumas divergências de opiniões sobre a definição da arquitetura e do papel do arquiteto, mas é certo dizer que, no geral, existe um consenso a respeito do essencial.
O Application Architecture Guide da Microsoft faz uma enumeração das definições mais coerentes e tenta relacioná-las.
O trecho a seguir é tradução do livro.
No último post apresentei o uso de Mocks para conseguir testar as classes que ainda estão sendo desenvolvidas usando objetos das quais elas dependem sem ter que implementar tais objetos. Neste post, como era de se esperar, eu vou explorar melhor o uso do Rhino Mocks, mostrando as principais opções que ele dispõe no uso de Mocks.
Você está efetuando os testes sobre sua camada de negócios, e alguns deles farão alterações no banco de dados, como a inclusão de um novo cliente, como mostrado no primeiro exemplo desta série, embora ele tenha sido muito tosco, conforme já admiti no post anterior. O que te incomoda são todos os vermelhos que irão surgir quando os testes tentarem fazer a inclusão de um cliente que já existe, e aí você vai lembrar que tem que limpar a base de testes sempre antes de executá-los.
E quando executar todos os testes, precisará verificar se os arquivos de Log foram devidamente criados no disco. Se os e-mails que o sistema deveria enviar foram devidamente enviados. E tantas outras evidências a colher em tantos lugares que não fazem parte do escopo de seus testes.
No fim das contas, tudo o que você precisa saber é se o seu software está se comportando como deveria. E você pode fazer isso executando um select na tabela de customers pra saber se o teste realmente inseriu alguém lá, ou pode simplesmente procurar algum meio de garantir que seu código faz isso sem que isso realmente ocorra.
Conheça o uso de Mocks.
Continuar lendo ‘TDD – Parte 03: Saiba como seu código se comporta’
Olá, Pessoal.
Nesta semana eu retomo os posts sobre TDD. Ainda tem algumas coisas bacanas pra explorar e provavelmente sairão uns dois posts sobre o assunto ainda esta semana. Mas enquanto estes posts não ficam prontos, eu vou postar aqui uma recomendação de download.
Este post não é meu, e sim do Waldemir Cambiucci. Estou apenas repassando:
Você que é arquiteto ou líder de desenvolvimento, que possui um time de desenvolvedores e pessoal técnico, não deixe de indicar esse material para seu pessoal:
Download de conteúdo técnico gratuito do MSDN para desenvolvedores
http://blogs.msdn.com/jpclementi/archive/2010/04/29/download-de-conte-do-t-cnico-gratuito-do-msdn-para-desenvolvedores.aspx
Entre os principais links, muito material sobre:
Azure, ASP.NET, .NET Framework 3.5, .NET Framework 4.0, Migração de Tecnologias, Silverlight 3.0 + Expression, Silverlight 4, Segurança no Desenvolvimento
SQL e Acesso a Dados, Visual Studio 2010 e .Net Framework 4.0, WCF, WF, WPF e Windows Server 2008.
Stay Sharp.
Este post é uma tradução de um post que li no blog do UncleBob.
Como eu já disse antes, não há nada particularmente errado com a atual mania por certificação. Se você quer ser certificado pelo custo de um curso de 2 dias, dê tudo para se certificar. Se você quer certificar pessoas por assistirem seu curso de 2 dias, dê tudo para dar o curso e entregar os certificados. É tudo muito bom. Faça dinheiro. Seja frutífero e faça multiplicar.
27
abr
10
TDD – Parte 2: 1, 2, 3… Testando
No último post eu dei uma breve introdução ao TDD. Muito breve, por sinal. Que só serviu mesmo para entendermos que é, acima de tudo, uma prática de design. Além de dar uma breve olhada em como fazer um teste.
Neste post, minha intenção é dar um pouco mais de sentido à prática do TDD fazendo alguns testes em cima de uma cesta de compras. Com isto, pretendo deixar um pouco mais claro a idéia de “Especificação Executável”.
26
abr
10
TDD – Parte 1: É sobre Design.
TDD já não é exatamente uma modinha faz um bom tempo. Não se trata mais de 3 letrinhas pra colocar na sopa do currículo. Se trata de uma prática aprovada pela comunidade e seu uso já é bastante expressivo no mercado. De fato, o TDD já não precisa mais convencer quase ninguém a respeito da sua eficiência quando bem utilizado, e o problema está somente aí: fazer bom uso dele.
E para saber fazer bom uso dele é necessário entendermos uma coisa simples: TDD é de Test-Driven Design. Mas o que muita gente faz é focar no T de Test e esquecer do D de Design. Não se iludam: o T é o aspecto menos importante da sigla. O que realmente importa para nós aqui é o segundo D do TDD.
