Relação entre testes, design e métricas

assunto.txt

Pessoal, gostaria de saber como vocês endereçam as questões que farei após explicar o cenário 
abaixo. Pra mim, é muito claro que todas podem ser respondidas com um belo "depende", contudo, 
vamos focar as respostas no que atenderia a maioria dos casos (lembrando que esse é um cenário
muito simplório).

-- CENÁRIO -----------------------------------------------------------------------------------------

Um desenvolvedor codificou inicialmente a classe (escrita em C#) no gist "exemplo_antes.cs". 
Após aplicar um refactoring, ele chegou no resultado mostrado no gist "exemplo_depois.cs".
Algumas métricas foram coletadas antes e depois do refactoring (vide gist "métricas.txt").

Obs.: Esse código foi tirado daqui -> 
http://whileicompile.wordpress.com/2010/09/14/what-is-too-simple-and-small-to-refactor-as-clean-code

-- QUESTÕES ----------------------------------------------------------------------------------------

1) De modo geral, podemos ter como prática que o set de testes deve, no mínimo, ter o mesmo número 
   de testes que o resultado do indicador CC (cyclomatic complexity)? Por exemplo, se um método tem 
   5 de CC, ele deve ter no mínimo 5 testes escritos para ele. 
   Notas: a) estou considerando apenas um assert por método de test. 
          b) não considerando a eficácia do teste escrito.

2) Membros privados podem ser ignorados nos testes? Devemos garantir os testes pelos membros 
   públicos observando a cobertura de código dos testes. Isso é suficiente? 
   Nota: sem entrar no mérito da necessidade ou não de 100% de cobertura. A intenção aqui é
   deduzir uma relação entre métricas (total de membros privados/publicos) e testes.

3) Quando, através de métricas, chegamos a conclusão que o código ficou mais complexo, é uma boa
   estratégia considerar LoC (lines of code) como indicador para comparar "antes" e "depois"? Que
   outras métricas vocês considerariam?

4) Qual a melhor "unidade" para orientarmos a escrita de testes (de unidade, claro): método, classe,
   assembly, assunto de negócio ou outra? (estou falando aqui de "Testes de Unidade": qual unidade
   você comumente utiliza?)

exemplo_antes.cs

/* Classe inicial, antes do refatoring */ 
using System;

namespace CleanCode.Before
{
    public class WageCalculator
    {
        public static float Calculate(float hours, float rate, bool isHourlyWorker)
        {
            if (hours < 0 || hours > 80)
                throw new ArgumentException();

            float wages = 0;

            if (hours > 40)
            {
                var overTimeHours = hours - 40;
                if (isHourlyWorker)
                    wages += (overTimeHours * 1.5f) * rate;
                else
                    wages += overTimeHours * rate;

                hours -= overTimeHours;
            }
            wages += hours * rate;

            return wages;
        }
    }
}

exemplo_depois.cs

/* Classes geradas, após refactoring */ 
using System;

namespace CleanCode.After
{
    public abstract class WageCalculatorBase
    {
        public float HoursWorked { get; protected set; }
        public float HourlyRate { get; protected set; }

        public WageCalculatorBase(float hours, float hourlyRate)
        {
            if (hours < 0 || hours > 80)
                throw new 
                    ArgumentOutOfRangeException("Hours must be between 0 and 80.");

            HoursWorked = hours;
            HourlyRate = hourlyRate;
        }

        public abstract float Calculate();
    }

    public class WageCalculatorForContractor : WageCalculatorBase
    {
        public WageCalculatorForContractor(float hours, float hourlyRate)
            : base(hours, hourlyRate)
        {
        }

        public override float Calculate()
        {
            return HoursWorked * HourlyRate;
        }

        public static float Calculate(float hours, float hourlyRate)
        {
            WageCalculatorForContractor payCalc = new 
                  WageCalculatorForContractor(hours, hourlyRate);
            return payCalc.Calculate();
        }
    }

    public class WageCalculatorForEmployee : WageCalculatorBase
    {
        public WageCalculatorForEmployee(float hours, float hourlyRate)
            : base(hours, hourlyRate)
        {
        }

        public override float Calculate()
        {
            if (IsOvertimeRequired)
                return CalculateWithOvertime();
            return CalculateWithoutOvertime();
        }

        protected bool IsOvertimeRequired
        {
            get
            {
                return HoursWorked > 40;
            }
        }

        protected float CalculateWithoutOvertime()
        {
            return HoursWorked * HourlyRate;
        }

        protected float CalculateWithOvertime()
        {
            float overTimeHours = HoursWorked - 40;
            return (overTimeHours * 1.5f + 40) * HourlyRate;
        }

        public static float Calculate(float hours, float hourlyRate)
        {
            WageCalculatorForEmployee payCalc = new 
                  WageCalculatorForEmployee(hours, hourlyRate);
            return payCalc.Calculate();
        }
    }
}

métricas.txt

	Type	Member					CC	LoC 	 	 					 
--------------------------------------------------------------------
CleanCode.After........................................[18]    [27]
	WageCalculatorBase..............................(8)    (9)
		Calculate() 				 1	0
		HourlyRate.get()			 1	1
		HourlyRate.set(float) 			 1	1
		HoursWorked.get() 			 1	1
		HoursWorked.set(float) 			 1	1
		WageCalculatorBase(float, float)	 3	5
	WageCalculatorForContractor.....................(3)    (5)
		Calculate() 				 1	2
		Calculate(float, float) 		 1	2
		WageCalculatorForContractor(float,float) 1	1
	WageCalculatorForEmployee.......................(7)    (13)
		Calculate() 				 2	3
		Calculate(float, float) 		 1	2
		CalculateWithoutOvertime() 	  	 1	2
		CalculateWithOvertime() 		 1	3
		IsOvertimeRequired.get() 		 1	2
		WageCalculatorForEmployee(float, float)	 1	1
CleanCode.Before........................................[6]   [14]
	WageCalculator..................................(6)   (14)
		Calculate(float, float, bool) 		 5     13
		WageCalculator()			 1	1

Oi Tucaz, Calcular mtrica (e avalia-las) no coisa de outro planeta! No entendi pq isso te parece to impossvel. 2012/4/11 tucaz < [email protected]

@juanplopes, @mauricioaniche: Quem faz nossa realidade somos ns, disso eu sei, mas ainda assim vou insistir neste ponto. Ando sem muita vontade de cantar uma bela cano, mas nosso ambiente mercadolgico hoje em dia no ajuda muito. Tentando fazer um trabalho de team lead, a maioria das vezes eu lido com gente que tem dificuldade em fazer o FizzBuzz. Outro dia passei como teste pra um desenvolvedor "Senior" o Mars Rover da TW e o cara insistiu at o final que o exercicio estava errado e no tinha jeito de resolver. Sei que esse mimimi todo no ajuda, mas acho que na maioria dos casos achamos que o problema esta na falta de conhecimento OO, no processo errado ou na falta de patterns ou sei-la-mais-oque. No entanto, acredito fortemente que o problema esta no bsico. O filtro de entrada hoje muito baixo. Falei todo esse bla bla simplesmente pelo seguinte. Mtricas so importantes, teis pra caramba e bem legais, mas no so prticas na maioria dos cenrios ento acho que no vale muito a pena discutir isso. a mesma coisa que perguntar se podemos ir pra Lua. O caboclo vem e responde que sim e tudo mais, que fcil. No entanto ningum vai. Ou seja, na prtica mesmo, apesar de ser possvel, no . Acho que a melhor analogia o may e can em ingls. We can, but may not. @ldaniel: Concordo contigo. Acho que esse tipo de coisa pra um dos poucos caras que ta ali distante do cdigo (no dia-a-dia), mas olhando por cima pra empresa como um todo. No sei no, mas IMO esse papel ta cada vez mais raro j que a qualidade base de tudo est cada vez pior, ainda mais com o monte de tecnologia nova que sai e que s complica mais a vida dos ja no to bons desenvolvedores. Bo, ignorem o velho chato aqui resmungando da vida, porque faz todo sentido o assunto. --- Reply to this email directly or view it on GitHub: https://gist.github.com/2149474

## Mauricio Aniche www.aniche.com.br @mauricioaniche

@tucaz não consigo deixar de lembrar das discussões do DNAD em 2008, quando tudo começou. poxa, era exatamente isso aqui. que coisa legal.

... ah saudosismo... =P

@ldaniel

Métricas não são forminhas de bolo, mas estabelecer que elas (muitas vezes sozinhas) são obrigatórias para um bom design é nocivo.

Mas o que eu estava falando, na verdade, são desenvolvedores que não pensam em nada além da receita que seguem para desenvolver uma funcionalidade. Por isso tantas perguntas sobre DDD, repositórios, camadas, etc. no DNA. Por que a grande massa não quer ter que pensar. Quer "comprar" uma modelagem pronta na "prateleira das boas práticas" e usar.

@tucaz @mauricioaniche

pois é, eu continuo batendo na tecla de que métricas (as mais comuns, pelo menos) são muito baratas para serem tiradas (custo, tempo, esforço etc). acho que talvez o problema seja um pouco de tudo:

• zilhões de tecnologias e possibilidades de estudo hoje em dia
• banalização do skill necessário para um desenvolvedor
• alta oferta de empregos e poucos profissionais (bons) disponíveis
• sei lá, tudo pode ser usado como "muleta" hoje em dia...

a impressão que tenho quando olho para o grupo que está reunido aqui respondendo essas questões, é que não representamos os "fodões" da área de TI. caramba, fazer um trabalho bem feito deveria ser a meta básica de qualquer um (independente de contexto, pelo brio mesmo, poxa). no entanto, tenho que concordar com o Tuca quando ele se desanima com o atual mercado.

@juanplopes

sim, concordo com tudo.

@mauricioaniche:

É "impossível" porque o desenvolvedor que ta ali do meu lado todo dia tem dificuldade em compreender como funciona um ORM, javascript básico e até HTML e CSS. Outro dia pedi pra um cara mudar uma classe CSS e ele não sabia como fazer. E isso não é nem aqui no Brasil somente. Esse caso em especifico aconteceu nos EUA então esse problema não é exclusividade nossa.

Imagina falar pra ele que o código dele tem uma complexidade enorme por causa dos caminhos que os IF's geram? Ou pedir pro cara refatorar pra deixar mais coeso? Não é prático.

Se olharmos pro indivíduo dentro do grupo, talvez até seja possível, mas disseminar esse comportamento pra um grupo de desenvolvedores que tem outras motivações é impraticável.

@ldaniel, mais uma vez vou ter que concordar com você que a discussão está interessante. Fazia tempo que eu não via algo assim, onde o pessoal não da carteirada pra fugir do assunto e provar um ponto. Way to go!

@tucaz

Nunca fiz um estudo formal para tentar confirmar isso, mas tenho a sincera impressão que desenvolvedores despreparados assim geram mais prejuízo que valor nos produtos em que desenvolvem.

Não que desenvolvedores iniciantes não possam trabalhar, mas por esse motivo sou a favor de code review ou (para os mais xp-fans) pair programming. É claro que se a proporção de desenvolvedores iniciantes for absurdamente maior que a de experientes, o custo disso fica inviável. E talvez seja irreal na maior parte das empresas com o mercado que temos.

@ldaniel

Curiosamente, sem querer puxar sardinha, eu vejo que a comunidade Java tem muito mais apego às métricas que a .NET. Em .NET você tem dificuldade até em encontrar ferramentas adequadas para tirar essas métricas.

Oi Tucaz, Eu entendo. Mas puxa, no sei se faz sentido parar de tentar melhorar, simplesmente pq a massa no acompanha. No acompanha infelizmente pq qquer um pode virar programador. Vc compra o livro de PHP e arranja emprego. No deveria ser assim, mas a regra de mercado. Vai de vc fazer um filtro. difcil. Mas felizmente, nas ltimas empresas que passei (pelo menos 3) a equipe /era excelente. 2012/4/11 tucaz < [email protected]

@mauricioaniche: "impossvel" porque o desenvolvedor que ta ali do meu lado todo dia tem dificuldade em compreender como funciona um ORM, javascript bsico e at HTML e CSS. Outro dia pedi pra um cara mudar uma classe CSS e ele no sabia como fazer. E isso no nem aqui no Brasil somente. Esse caso em especifico aconteceu nos EUA ento esse problema no exclusividade nossa. Imagina falar pra ele que o cdigo dele tem uma complexidade enorme por causa dos caminhos que os IF's geram? Ou pedir pro cara refatorar pra deixar mais coeso? No prtico. Se olharmos pro indivduo dentro do grupo, talvez at seja possvel, mas disseminar esse comportamento pra um grupo de desenvolvedores que tem outras motivaes impraticvel. @ldaniel, mais uma vez vou ter que concordar com voc que a discusso est interessante. Fazia tempo que eu no via algo assim, onde o pessoal no da carteirada pra fugir do assunto e provar um ponto. Way to go! --- Reply to this email directly or view it on GitHub: https://gist.github.com/2149474

## Mauricio Aniche www.aniche.com.br @mauricioaniche

@juanplopes,

compartilho da sua impressão. Tanto é que ultimamente adotei a postura de aceitar mais trabalho (não tanto assim :P) ao invés de contratar gente despreparada que vai gerar mais trabalho do que já temos.

@mauricioaniche,

foi por isso que falei que sou velho chato. Com certeza não é motivo pra desanimar. Essa imagem de desanimado minha é mesmo uma imagem. Apesar dos pesares, ainda tenho energia pra tentar promover um monte de coisa bacana.

Quanto a equipes boas, sei que elas existem. Não em tantos lugares, mas também não estão em extinção. Só não consegui unir o útil ao agradável ainda ($$$). Infelizmente empresas ruins pagam mais, afinal sempre precisam de gente pra resolver problemas, né?

@tucaz

Vem pro Rio. Estamos contratando!

Brincadeira...

Não, é sério. Pode vir. :P

Acho que cheguei só um pouco atrasado kkk, mesmo recebendo no twitter o link uma refatoração de um código legado não me permitiu participar :D

@ldaniel interessante a discussão, a única refatoração que gostei foi a do @juanplopes e agora minhas respostas.

1- Sim, no mínimo, quando preciso testar códigos assim geralmente verifico a cobertura de código para garantir que passei por todo lugar.

2 - Essa depende mesmo, testo métodos privados mas ai tenho que concordar com o @juanplopes talvez tenha um probleminha em precisar testar esses caras :)

3 - Cara não sei, acho que LoC não vai ajudar a dizer que ficou mais complexo, muita linha de código simples é melhor que pouca linha de código complexo :D. E ai depende do "feeling" que o @vquaiato disse. Agora pensando... e se além de LoC considerar número de testes? Acho que nesse exemplo o número de testes para o código refatorado acabaria maior do que com o código sem refatorar.

4 - Classe

Mais uma vez parabéns, sensacional a discussão aqui, todos foram geniais