<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\section{xUnit}
\label{sec:xunit}


Durante su trabajo en los laboratorios de Xerox Park\cite{XeroxPark},
Kent Beck desarrollo un framework para realizar test unitarios
en el lenguaje de programación {\it Smalltalk} que estaba desarrollando.
Dicho framework se llamaba sUnit\cite{sUnit}.
sUnit Permitía agrupar los tests en suites, el lanzamiento jerárquico de éstos y realizar para cada test la comparación entre el valor obtenido y el valor esperado para determinar la corrección de la funcionalidad testeada.
Este framework ha sido llevado a una gran variedad de lenguajes de 
programación ({\it JUnit}, {\it XSLTUnit}, {\it PhpUnit}, {\it PyUnit}...).
xUnit es el nombre con el que se designa genéricamente a todos estos frameworks.
Kent Beck desarrolló los frameworks xUnit al mismo tiempo que
fue madurando la práctica del Test Driven Development en los equipos en los 
que trabajaba.
No es de extrañar que los frameworks {\it xUnit} y la práctica del 
{\it Test Driven Development} estén íntimamente relacionados. Si {\it Test Driven Development} es la práctica, xUnit es la herramienta.

\begin{citation}
Los frameworks xUnit permitirán al usuario de nuestro framework de testeo de eficiencia organizar sus casos de tests en test suites, gestionar su 
ejecución ordenada y compartir código de configuración y limpieza entre casos 
de test.
Al mismo tiempo, también haremos servir frameworks xUnit para desarrollar con TDD el sistema.
\end{citation}

Aunque {\it xUnit} está pensado para hacer asserts, nos interesa partir de un framework ya existente para realizar los tests de eficiencia. 
De esta manera, podremos integrar las tareas de organización de los tests y la gestión de ejecución en nuestros tests de eficiencia.
La diferencia entre los tests convencionales de xUnit y los tests propuestos en nuestro framework es que, en nuestro caso, obviaremos los asserts.
Otro motivo para usar el modelo {\it xUnit} es la expansión y el alto grado de utilización de esta herramienta por todo el mundo.
Por lo tanto, no sería coherente que, para la creación de tests de eficiencia, hubiéramos creado una nueva estructura para la creación de tests porque, primeramente, cppUnit cubre todas las necesidades requeridas para la creación de los tests de eficiencia;
por otro lado, un cambio de estructura en los tests implicaría que el usuario tuviera que realizar un aprendizaje para conocer el funcionamiento, algo que es preferible evitar;
finalmente, el objetivo de la creación de estos tests es que los usuarios puedan compaginar los tests unitarios con los tests de eficiencia, de manera que se pueda mantener un equilibrio entre diseño y optimización, como ha sido explicado en el punto \ref{EficienciaDisenyo}.

El usuario de los tests de eficiencia desarrolla el código en {\it C++}, con lo cual, el framework de testeo deberá ser específico para este lenguaje.
El listado de frameworks {\it xUnit} libres para C++ está formado por {\it cxxtests, CppUnit, Boost.Test, CppUnitLite, NanoCppUnit, Unit++, MiniCppUnit, QtUnit, KDEUnit, 
QTest} entre muchos otros.
Los más usados son {\it CppUnit} y {\it cxxTests}.
Comparativamente, los dos frameworks tienen los requisitos básicos para ser usados como modelo ya que ambos soportan fixtures, suites, outputs diferentes y aceptan exceptions.
Debido a sus características, la integración de los tests de eficiencia es viable en cualquiera de los dos frameworks.
Si finalmente nos centramos en {\it cppUnit} es porque nuestros usuarios utilizan {\it cppUnit} de forma general y {\it MiniCppUnit} (del cual son los desarrolladores) en casos puntuales.


Para el desarrollo del proyecto hemos usado {\it pyUnit}, una herramienta de testeo unitario para {\it Python}.
La razón por la cual hemos usado la práctica de {\it Test Driven Developement} en el desarrollo es, en primera instancia, porque el proyecto está es una comunidad {\it Open Source}, con lo cual, el mantenimiento del software se realizará por todo aquél interesado en el proyecto.
Por ello es necesario seguir una metodología de desarrollo común para el buen entendimiento entre todos los desarrolladores y la metodología por la que hemos optado es por las metodologías {\it Extremme Programming}.
La otra razón es por mantener la cohesión ideológica entre el uso de la herramienta presentada y la creación de la misma.
Si se ha decidido usar {\it pyUnit} para realizar los tests es porque, aunque hay otras librerías como {\it Testoob} \cite{testToob} que también se basa en el modelo xUnit y extiende la funcionalidad de {\it pyUnit}, {\it pyUnit} es una librería estándar de {\it Python} y su uso asegura el funcionamiento de los tests en cualquier sistema.




</pre></body></html>