Incluye marco de prueba en git repo?

Question

Estoy haciendo que git y unidad prueben partes de mi flujo de trabajo habitual. Agradecería consejos sobre si los marcos de pruebas unitarias (no las pruebas mismas, sino el marco real) deberían incluirse en el repositorio de git de un proyecto.

Por un lado, parece que no debería, ya que los marcos son a) fácilmente disponibles en otro lugar yb) no exclusivos de un proyecto (estoy hablando de marcos populares como qunit para JS o simpletest en PHP) . En ese caso, tal vez un simple archivo léame en el repositorio indique la versión del marco y dónde obtenerlo sería suficiente.

Por otro lado, las pruebas SON parte del proyecto (y parte del repositorio), y necesitan el marco para ejecutarse, por lo que, para completar, tal vez el marco debería incluirse también.

Gracias.

Answer 1

Leer las respuestas a esta pregunta es interesante, ya que muestra una gama muy amplia de interpretaciones de muchos aspectos diferentes del desarrollo de software. Normalmente, creo que las dependencias de cualquier tipo no deberían almacenarse en el VCS (por VCS, me refiero a herramientas como git, hg, svn, cvs, y sistemas no más grandes que incorporan tales herramientas, como Xcode) porque eso es no es el trabajo del VCS. El seguimiento de la dependencia se deja mejor a una herramienta de embalaje. (Parece que mucha gente usa el VCS como una herramienta de empaquetado primitiva, que en mi humilde opinión es un gran error.)

Creo que debe aclarar lo que quiere decir con 'marco de prueba'. Para mí, la mayoría de mis suites de prueba son invocadas por el marco provisto por automake. Ciertamente no incluyo automake en mi repositorio de git, pero no hay problemas con las diferencias de versión en el futuro porque todo el marco de prueba generado por automake está incluido en el tarball de distribución. Entonces, realmente la pregunta retrocede un nivel más. Si está utilizando solo un VCS para rastrear sus lanzamientos, entonces tiene un problema porque realmente necesita tener el marco de prueba disponible cuando revisa una versión anterior del proyecto. Si el VCS es el único mecanismo de almacenamiento para recuperar versiones antiguas (es decir, no está utilizando ningún tipo de archivo de lanzamientos en tarballs), parece que se ve obligado a poner el marco en el VCS. Pero poner software externo en su VCS es, francamente, estúpido. La única razón para hacerlo es si está utilizando el VCS como su herramienta de distribución. Entonces, supongo que mi respuesta es: no coloque el marco en su VCS, pero coloque el marco en sus distribuciones. Si su VCS es su herramienta de distribución, entonces no hay una forma adecuada de lidiar con el marco de prueba.

Answer 2

Yo diría que no, porque están disponibles en cualquier otro lugar, y cualquier desarrollador experimentado ya debería tener esas bibliotecas disponibles.

Además, algunos IDE modernos (eclipse en particular) ya vienen con las bibliotecas de pruebas unitarias que usted necesita, por lo que no es crítico enviarlos con su fuente.

Answer 3

Casi siempre incluyo el marco (una buena debería ser unas pocas bibliotecas y ejecutables, por lo tanto no tan grande) - la fuente y las pruebas están versionadas, y si alguna vez vuelvo y obtengo la versión 1.2 de mi código desde 2001 , Quiero que las pruebas se ejecuten cuando realizo ese hotfix, para no fallar porque estoy usando el marco de prueba en el que cambié en 2006.

Sin el marco de prueba en control de fuente, agrego una cosa más que tengo para que coincida con las versiones de. Demonios, versionaría el compilador y las bibliotecas de idiomas allí también si fuera factible.

Si tiene una herramienta/plataforma de prueba gigante que no se puede poner fácilmente al lado (o no se puede poner junto legalmente), asegúrese de incluir un documento que diga qué herramienta, qué versión , y posiblemente cómo hacerlo junto con las pruebas.

Answer 4

Interesante pregunta. Sin embargo, no creo que el marco de prueba deba incluirse en un repositorio de aplicaciones.

Nombre los requisitos previos de su proyecto en un archivo Léame. Si tiene varios proyectos que usan el mismo marco de prueba, ya tiene el marco instalado y probablemente no desee descargarlo o instalarlo nuevamente para cada proyecto.

Answer 5

Incluyo DLL NUnit en todos mis repositorios con pruebas unitarias. De hecho, incluyo todo en el repositorio que necesito para compilar y ejecutar pruebas. Por supuesto, esto no es factible para algunos proyectos, pero cuando es factible, es muy fácil simplemente verificar el repositorio y comenzar a trabajar. No se requiere configuración.

Answer 6

No, no debe incluir marcos externos en su repositorio, a menos que realmente esté modificando los marcos para trabajar con su proyecto.

Dependiendo del idioma que esté utilizando, es posible que desee utilizar un archivo README o confiar en sus herramientas de embalaje; por ejemplo, ambos distutils de Python y Module :: Build de Perl permiten especificar qué módulos externos son necesarios para ejecutar las pruebas e instalarán las dependencias para sus usuarios.

Answer 7

Añadimos todos bibliotecas referenciadas a nuestros repositorios.

Esto tiene la ventaja de que tiene todos los componentes necesarios en un solo lugar. Si tienes una computadora nueva, simplemente tienes que instalar tu IDE de tu elección, verifica el repositorio y estás listo.

Esto también hace que sea más fácil generar un proceso de compilación en un servidor de compilación, ya que solo tiene que apuntarlo a su repositorio, que incluye todo lo necesario para una compilación (a pesar del .NET framework). Por lo tanto, es fácil crear una compilación de una versión anterior sin problemas de versión.

Answer 8

Desde un mundo de Python, incluiría las dependencias en mi archivo setup.py. Los desarrolladores pueden buscarlos entonces.

Con tarballs, a veces incluyo un generated test file para que la gente pueda al menos hacer algunas pruebas de cordura antes de ejecutar el proyecto.