QUALIDADE DE
CÓDIGO
Test Driven Development
 Por que é importante?
 Código de produção testável
 Refatoração sem medo
 Código melhor estru...
Mocks
 Então como testar?
 Mocks
 Exemplo DataAccess
 Testar a conversão dos Feriados do SIAP em DateTime
 Biblioteca...
Exemplo: classe não testável
 Classe não testável:
Refatoração
 O código de produção
deve ser escrito o mais
simples possível para
passar
 Depois de escrever
vários testes...
Refatorando ConsultaArquivo
 Temos que testar a regra de obter o texto SQL
sem depender de um arquivo do
sistema, como?
...
ConsultaArquivo Refatorada
Testes de Integração
 Poderíamos testar o FileHelper, mas seria um teste
de Integração e não um teste de unidade.
 Seria...
Nomenclatura
 Nome classe de teste:
 NomeClasseTestadaDeve
 NomeClasseTestadaNomeMetodoDeve
 Nome dos métodos do teste...
Nomenclatura - AAA
 Arrange
 Organiza os objetos antes de executar o teste
 Act
 Executa o método que está testando
 ...
SUGESTÕES DE
MELHORIA
Opiniões e Debates
Muitas dependências
 Classe recebe vários parametros no construtor
 Talvez essa classe deva ser quebrada em mais
classes...
Business
 Acho que não devíamos ficar presos as
Business.
 Regra de negócio deve ser na Business, ok.
 Mas também poder...
Business
 Acho que poderíamos ter mais Business ao
invés de apenas Business relativas ao Model.
 Exemplo CRM:
CampanhaBu...
Parametros out
 ReadComplete
 Por que não retornar apenas uma classe e nessa
classe colocar todos os parametros out?
 C...
Factories
 São classes que funcionam como uma fábrica
de objetos.
 Às vezes para instanciar uma classe, é
requerido vári...
AtividadeFactory
 Poderia ser criado uma classe Factory que
recebesse os objetos destacados e retornasse
uma instancia de...
Dependência de Web Services
 Acho que não devíamos usar o Schema gerado
pelo wsdl
 Se o schema mudar, toda a aplicação t...
Referências
 Software Practices, Pluralsight
 Principles of Object Oriented Design
 Design Patterns
 Clean Code A Hand...
Upcoming SlideShare
Loading in...5
×

Qualidade de Código

72

Published on

Apresentação para a equipe .NET na empresa Dual.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
72
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Qualidade de Código

  1. 1. QUALIDADE DE CÓDIGO
  2. 2. Test Driven Development  Por que é importante?  Código de produção testável  Refatoração sem medo  Código melhor estruturado  O que não testar?  Cadastros  Leitura/Gravação de arquivos  Independência  Banco de dados  Arquivos do sistema  Arquivos de configuração
  3. 3. Mocks  Então como testar?  Mocks  Exemplo DataAccess  Testar a conversão dos Feriados do SIAP em DateTime  Biblioteca Moq.  Testes Unitários  Deve testar um único método. Todas as outras dependências que esse método usa devem ser mockadas.  Evitar métodos estáticos  Não é possível mocká-los  DateTime.Now  Exemplo Business & DateTime.Now  Mostrar código do SIGEP (ApontamentoServicoDeve)
  4. 4. Exemplo: classe não testável  Classe não testável:
  5. 5. Refatoração  O código de produção deve ser escrito o mais simples possível para passar  Depois de escrever vários testes e códigos de produção, pode-se perceber que há códigos duplicados ou que poderiam ser melhores escritos  Então chegou a hora de refatorá-los
  6. 6. Refatorando ConsultaArquivo  Temos que testar a regra de obter o texto SQL sem depender de um arquivo do sistema, como?  Dependency Inversion 1º • Vamos fazer a classe ConsultaArquivo não depender mais dos métodos estáticos da classe File 2º • ConsultaArquivo exigirá no construtor uma interface IFileHelper 3º • IFileHelper conterá 2 métodos: Existe(...) e LeTodoTexto(...) 4º • Mockamos o IFileHelper para testar o método ObterConsultaPorNome(...)
  7. 7. ConsultaArquivo Refatorada
  8. 8. Testes de Integração  Poderíamos testar o FileHelper, mas seria um teste de Integração e não um teste de unidade.  Seria um teste de Integração com o sistema de arquivos do windows  Testes de Integração se caracterizam por necessitarem de um ambiente preparado para o teste funcionar  Acesso a arquivos  Acesso ao banco de dados  Acesso a WebServices  Testar unidades em conjunto (integradas)
  9. 9. Nomenclatura  Nome classe de teste:  NomeClasseTestadaDeve  NomeClasseTestadaNomeMetodoDeve  Nome dos métodos do teste:  Deve ser uma ação que a classe testada deve fazer  Exemplos:  PedidoBusinessDeve  Quebrar_Pedidos_Por_Representante_Quando_Parametro_Estiver_ Setado  Retornar_Apenas_Pedidos_Faturados_Da_Conta_X  Totalizar_Itens_Pedidos_Corretamente  Lancar_Excecao_Quando_Pedido_Estiver_Bloqueado  Por quê?  Facilita o entendimento sobre o que está sendo testado  Facilita para o desenvolvedor escrever o teste
  10. 10. Nomenclatura - AAA  Arrange  Organiza os objetos antes de executar o teste  Act  Executa o método que está testando  Assert  Verifica as condições para que o teste passe  Por quê?  Testes mais organizados  Testes mais limpos  Bater o olho e saber o que e como certa funcionalidade está sendo testada
  11. 11. SUGESTÕES DE MELHORIA Opiniões e Debates
  12. 12. Muitas dependências  Classe recebe vários parametros no construtor  Talvez essa classe deva ser quebrada em mais classes  Agrupar os parametros em outra classe e fazer o construtor receber essa nova classe.
  13. 13. Business  Acho que não devíamos ficar presos as Business.  Regra de negócio deve ser na Business, ok.  Mas também poderíamos criar outras classes que a Business usa.  Exemplo: validação do Pedido é complexa  Talvez criar uma classe ValidadorPedido(Pedido)  Passar tudo o que é preciso para validar o Pedido  Na Business de Pedido chamar essa classe.  Atualmente os métodos das Business possuem muito código e as regras estão obscuras
  14. 14. Business  Acho que poderíamos ter mais Business ao invés de apenas Business relativas ao Model.  Exemplo CRM: CampanhaBusinessComplement  Possui método CriarAgendamentos  Poderia ser criado uma Business relativa a Agendamentos, pois a criação de Agendamentos é complexa e poderia ser isolada.
  15. 15. Parametros out  ReadComplete  Por que não retornar apenas uma classe e nessa classe colocar todos os parametros out?  CreateComplete  Por que não receber essa mesma classe que foi criada no item anterior ao inves de vários parametros out?  Acho que não devíamos ficar presos aos Models.  Mais classes poderiam ser criadas para que as responsabilidades sejam divididas.
  16. 16. Factories  São classes que funcionam como uma fábrica de objetos.  Às vezes para instanciar uma classe, é requerido vários parametros ou algumas regras especificas.  Essas regras poderiam estar encapsuladas em uma Factory  Exemplo CRM:
  17. 17. AtividadeFactory  Poderia ser criado uma classe Factory que recebesse os objetos destacados e retornasse uma instancia de AtividadeInfo.
  18. 18. Dependência de Web Services  Acho que não devíamos usar o Schema gerado pelo wsdl  Se o schema mudar, toda a aplicação terá que ser alterada  Solução  Criar nossas próprias classes  Criar camada intermediária entre nossas classes e o schema  Converter nossas classes para o schema  Converter o schema para nossa classe  Se schema mudar, precisamos mexer apenas nessa camada de conversão  Exemplo ruim: DualNFe usa os schemas  Exemplo bom: PortalTiss usa classes próprias
  19. 19. Referências  Software Practices, Pluralsight  Principles of Object Oriented Design  Design Patterns  Clean Code A Handbook of Agile Software Craftsmanship, Robert C. Martin  DDD Quickly, Abel Avram & Floyd Marinescu  Resumo de DDD por Eric Evans
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×