Question

Me gustaría conocer cómo resolveríais el siguiente escenario.

Tengo una clase TextArea, que utilizainternamente dos clases de una librería de terceros, TextBox3rdParty y Renderer3rdParty. Las dos clases de terceros colaboran entre ellas a la hora de inicializar a mi TextArea.

Quiero configurar un test harness que me permita instanciar mi TextArea e inicializarlo, sin introducir dependencias de terceros en el mismo.

Documentándome un poco, veo que una solución típica es extraer la interfaz que necesitemos de cada clase de terceros, y usar esa interfaz en mi TextArea, de forma que en el test harness usaría sendos mocks de esas interfaces, y eliminaría las dependencias.

Por otro lado, en el código de producción, para que mi TextArea funcione, necesito que use realmente la librería de terceros, Para ello me creo sendos wrappers, TextBox3rdPartyWrapper, y Renderer3rdPartyWrapper, que implementan las interfaces.

En el código de inicialización de mi TextArea, necesito pasar a Renderer una instancia de TextBox. Y aquí viene mi primera duda. Lo que hago en Renderer3rdPartyWrapper, método addTextBox(TextBox* textBox), es un cast de TextBox a TextBox3rdPartyWrapper, y hacer que ésta colabore con el Renderer3rdParty de terceros:

void Renderer3rdWrapper::addTextBox(TextBox* textBox)
{
      TextBox3rdPartyWrapper* textBox3rdPartyWrapper = dynamic_cast<TextBox3rdPartyWrapper*>(textBox);
if (textBox3rdPartyWrapper)
  mRenderer3rdParty->addTextBox(textBox3rdPartyWrapper->getTextBox3drParty());
}

Un diagrama UML explicativo de la situación es el siguiente:

Y como últimas preguntas/reflexiones: ¿La técnica de "Wrap and Mock" la usaríais siempre y en todos los casos? ¿Dónde ponéis el límite cuando vuestro software depende tanto de un framework de terceros?

Espero que no sea una pregunta demasiado genérica.
¡Gracias!

Answer 1

Hola Roberto,

es un tema complejo que da para debatirlo largo y tendido... así que intentaré hacer un resumen:

Tu planteo es correcto, ya que para hacer test unitarios de clases que tengan dependencias, se deben crear Objetos Mock que devuelvan valores fijos y que sirvan para la ejecución de cada test, De esta forma, el testeo se hace en un ambiente controlado. http://es.wikipedia.org/wiki/Objetos_mock

Por otra parte, si bien no es una ley pero sí es regla general, lo único que pasarás por testeos unitarios serán los Objetos del Modelo, con lo que los Mock se crearán para representar a otros Objetos del Modelo que todavía no estén implementados, o para simular la interacción con el ambiente externo como una DB, un sensor o una entrada del usuario.

Por todo esto, salvo que las bibliotecas/frameworks de terceros que uses sean parte del modelo, se prefiere usar algún patrón de diseño con el que desacoplar las dependencias, llegando al extremo de usar Inyección de Dependencias o "Dependency Transformers".

Cuál es el límite para crear Objetos Mocks? Generalmente no debes hacerte esta pregunta, porque si estás haciendo por ejemplo TDD (Test Drive Development) entonces te habrán entregado la batería de test con los que cumplir, y tendrás que hacer tantos mocks como haga falta para pasarlos a todos.

En tu caso y sin conocer más del diseño del software, si TextArea es parte del Modelo, deberías poder desacoplarlo mejor del Render y del TextBox, cuyos nombres sugieren que son parte de la Vista.

Si en cambio el TextArea es parte de la Vista, lo más adecuado no es hacer un Test Unitario, sino hacer testeo desde la interfaz con un robot que simule la interacción con el usuario: http://en.wikipedia.org/wiki/List_of_GUI_testing_tools

Igual Roberto, no hay una línea definida que separe estos aspectos del testeo: hay buena parte de necesidad, pautas del cliente y gustos.

Saludos cordiales