segunda-feira, 17 de março de 2008

Devo mockar métodos de classes "utilitárias"?

Se considerarmos que esses métodos estão fora do escopo testado ou que serão testados isoladamente, a resposta é não, porém, pensando com cuidado, percebo que esses métodos normalmente são recheados de Reflections e Generics para serem o mais genérico possível, e pensando em algumas situações acho que podemos mudar de opinião.

Temos aqui na empresa uma classe CollectionUtil onde criamos métodos para manipular Collections. Nesta classe criamos um método não tão genérico quanto o possível, porém, o suficiente para a nossa utilização, sendo que me deparei com uma coisa:

O método é responsável por receber uma Collection e retornar um Array de ids (todas as nossas entidades tem esse atributo):

 0: public Long[] convertCollectionToArrayIds(
1: Collection coll)
2: {
3: Method mKey = null;
4: Long[] ids = new Long[coll.size()];
5:
6: try
7: {
8: int count = 0;
9: for(T clazz: coll)
10: {
11: mKey = clazz.getClass().
12: getMethod("getId");
13: ids[count] = (Long) mKey.invoke(
14: clazz,new Object[]{});
15: count++;
16: }
17:
18: return ids;
19: }
20: catch(Exception e)
21: {
22: e.printStackTrace();
23: return null;
24: }
25: }

Imagine uma situação onde alguém, não importa o porque, não use o atributo "id" e sim "cod" ou um erro de digitação e sai um "ide", ou qualquer outra coisa, pensando nisso, vejo que a melhor saída é: Não mockar o método "utilitário".

Use o bom senso, um método utilitário que envie um email ou que não seja tão genérico assim, pode ser mockado. Outra alternativa é enriquecer o método "utilitário", fazendo verificações se a entidade possui o atributo "id".