Usando Tessy con Subversion

Tengo un proyecto C embedded que usa subversión para control de fuente. Quiero usar Tessy para testings unitarias y también archivar estas testings en subversión. Sin embargo, genera muchos files pequeños que harán que el análisis de diferencias para el código fuente real cambie un dolor real. Tratar de ver realmente los cambios en la fuente cuando hay cientos de files relacionados con Tessy modificados lo hará imposible.

¿Alguien sabe si hay una configuration para tener estos almacenados en un formatting less problemático o cualquier sugerencia para una solución viable? Lo que sería ideal es si pudiera almacenar todo, como, por ejemplo, un file xml; esto haría que el directory de navigation sea más fácil y permitiría que el contenido real también sea legible para el ser humano.

¿Algunas ideas?

Sé que esta es una vieja pregunta …

¿Alguien sabe si hay una configuration para tener estos almacenados en un formatting less problemático o cualquier sugerencia para una solución viable?

  • La forma recomendada por TESSY es utilizar la característica de save la database que se encuentra en el menu Archivo (y en una variedad de menus con el button derecho). Esto crea un file .tmb binary que contiene todo lo relacionado con sus testings. Por defecto, el file .tmb se almacena en el directory de la copy de security en su carpeta Tessy Project. La carpeta de configuration, la carpeta de respaldo y el file PDBX se almacenarían todos en SVN. Consulte el Manual de uso de Tessy (Copia de security, restauración, capítulo de control de versiones) para get más detalles.

Lo que sería ideal es si pudiera almacenar todo, como, por ejemplo, un file xml; esto haría que el directory de navigation sea más fácil y permitiría que el contenido real también sea legible para el ser humano.

  • Eso sería ideal, pero desafortunadamente no es realmente una opción. Tener todo almacenado como un file binary hace que sea imposible hacer una diferencia útil. El otro problema con este método es que desconecta un cambio de la testing del file que se comtesting en SVN, a less que el verificador realice específicamente un guardado de la database.

Sí, me doy count de que los frameworks de testing de xUnit no tienen esas limitaciones, pero Tessy tiene algunas características (como compatibilidad con MCDC y DO178B) que los frameworks xUnit no tienen incorporados.

Entonces, ¿cómo trabajas en este entorno? Palabra key – Disciplina.

Establecemos procedimientos internos para quién y cómo se actualizan las testings. Cuando se siguen los procedimientos, podemos tratar con las limitaciones presentadas anteriormente. No es óptimo, pero con cierta disciplina interna puede funcionar.