c# - Problemas con el atributo DeploymentItem
visual-studio unit-testing (20)
No use DeploymentItem .
Es muy difícil de configurar correctamente y no funcionaba con mi corrector de prueba ReSharper ni con el nativo de MSTEST en Visual Studio 2017.
En su lugar, haga clic con el botón derecho en su archivo de datos y seleccione propiedades . Seleccione Copiar en el directorio de salida: Siempre .
Ahora en tu prueba, haz esto. El directorio es simplemente el directorio del archivo relacionado con el proyecto de prueba. Fácil.
[TestMethod()]
public void ParseProductsTest()
{
// Arrange
var file = @"Features/Products/Files/Workbook_2017.xlsx";
var fileStream = File.Open(file, FileMode.Open);
// etc.
}
Advertencia. No tengo idea si esto funciona bien con los sistemas automatizados de compilación y prueba. No estoy allí todavía.
Actualmente estoy manteniendo un sistema "antiguo" escrito en C # .net, eliminando algunas características obsoletas y haciendo algunas refactorizaciones. Gracias a Dios, el chico anterior escribió algunas pruebas unitarias (MSTests). Me sentía bastante cómodo con las pruebas JUnit, pero aún no hacía mucho con MSTests.
Los métodos de prueba tienen un atributo DeploymentItem , que especifica un archivo de texto que es analizado por el método de lógica de negocios que se está probando y un 2nd DeploymentItem donde solo se ha especificado una ruta que contiene un grupo de archivos TIF que deben implementarse también.
[TestMethod()]
[DeploymentItem(@"files/valid/valid_entries.txt")]
[DeploymentItem(@"files/tif/")]
public void ExistsTifTest()
{
...
}
Las pruebas funcionaron antes, pero ahora tuve que cambiar los nombres de los archivos TIF contenidos en el directorio / files / tif. De acuerdo con una regla, los nombres de los archivos TIF deben coincidir con un cierto patrón que también se verifica mediante el método ExistsTifTest() . Ahora tuve que cambiar los nombres de los archivos para adaptarlos a los nuevos requisitos y de repente los archivos TIF ya no se implementan como antes.
¿Puede alguien darme una pista de por qué sucede esto o cuál puede ser la causa? Lo mismo ocurre también si agrego un nuevo archivo de texto, digamos "my2ndTest.txt" junto a "valid_entries.txt" en el directorio / files / valid / con el atributo DeploymentItem correspondiente en el método de prueba. El archivo no se implementa?
Obtuve las imágenes ahora desplegadas definiendo la ruta de implementación directamente en el testrunconfig, pero me gustaría entender por qué ocurren estas cosas o por qué, por ejemplo, mi nuevo archivo "my2ndTest.txt" no se implementa mientras que los demás lo hacen.
Como siempre encontré el atributo DeploymentItem en un lío, realizo el despliegue de dichos archivos usando el script post-build. - Asegúrese de que los archivos que desea copiar tengan la propiedad Copiar siempre establecida. - Modifique el script de post-construcción del proyecto de prueba para copiar los archivos de la carpeta de destino de compilación (Bin / Debug) a la ubicación donde su prueba los está esperando.
Después de probar todas las otras sugerencias enumeradas aquí, todavía no podía entender qué estaba pasando. Finalmente, descubrí que no había ningún archivo de configuración seleccionado en el menú de Configuración de prueba / prueba, lo que significaba que la Implementación no se estaba habilitando. Hice clic en la opción de menú Probar / Probar configuración / Seleccionar archivo de configuración de prueba, seleccioné el archivo Local.TestSettings, luego todo funcionó.
En VS2010, mi Local.testsettings tenía desactivada la opción "Habilitar implementación" y el atributo DeploymentItem no funcionaba. Lo revisé y todo funcionó bien. ¡Espero que esto ayude!
Estaba teniendo grandes problemas al intentar que los archivos se desplegaran, probando todas las sugerencias anteriores.
Luego cerré VS2010; lo reinicié, cargué la solución y todo funcionó. (!)
Hice algunas comprobaciones; Después de configurar el indicador ''Habilitar implementación'' en local.TestSetting, no debe simplemente volver a ejecutar la prueba desde la ventana Resultados de la prueba. Debe eliminar la prueba anterior de la interfaz de usuario, por ejemplo, ejecutando una prueba diferente o reabriendo la solución.
Esto probablemente no se relaciona con su problema exacto, pero aquí hay un par de consejos que encontré con el atributo [DeploymentItem].
- El directorio Copiar a salida debe establecerse en Copiar siempre.
NO funciona cuando se usa con el atributo [TestInitialize]
[TestInitialize]
[DeploymentItem("test.xlsx")]
public void Setup()
{
Debería estar en su [TestMethod], por ejemplo
[TestInitialize]
public void Setup()
{
string spreadsheet = Path.GetFullPath("test.xlsx");
Assert.IsTrue(File.Exists(spreadsheet));
...
}
[TestMethod]
[DeploymentItem("test.xlsx")]
public void ExcelQuestionParser_Reads_XmlElements()
{
...
}
He estado trabajando en esto en VS2013. Mis hallazgos para que esto funcione:
- El directorio Copiar a salida debe establecerse en Copiar siempre: OBLIGATORIO.
- "Habilitar implementación" en. TestSettings: NO ES NECESARIO. Lo hice funcionar sin un archivo .TestSettings en absoluto.
- Especificando una carpeta como 2do parámetro: OPCIONAL. Da forma al diseño de la carpeta de salida, funciona bien sin.
- ESPACIOS en el nombre de archivo: esto me causó un dolor de cabeza: el archivo nunca se copió. Eliminar los espacios arreglados esto. Aún no he investigado los caracteres de escape.
Un consejo que también aprendí de la peor manera: no olvides agregar este atributo a cada prueba individual. El archivo se copia en la primera prueba atribuida en el testrun, pero permaneció ausente cuando el orden de las pruebas cambió y las pruebas no atribuidas intentaron encontrar primero el archivo.
Hemos pasado mucho tiempo con el problema de elementos de implementación para resolverlo en la prueba de unidad local y también en la prueba de unidad de equipo. No es facil.
Muy buena herramienta para depurar este problema es ProcessExplorer . Con Process Explorer, puede verificar dónde está Visual Studio buscando los elementos de implementación y realizar la corrección al proyecto. Simplemente filtre toda la operación de archivo donde la ruta contiene su nombre de archivo de deployment y lo verá.
Mi gran "problema" fue la forma en que DeploymentItem maneja los directorios. Estaba usando la versión de dos parámetros con ambos como ruta de directorio que contiene subdirectorios que quería desplegar. Inicialmente, no me di cuenta de que solo copia las cosas en la RAÍZ del directorio y no toda la estructura de carpetas recursivas.
Básicamente tenía [DeploymentItem (@ "Foo /", @ "Foo /")] y esperaba que desplegara mi Foo / Bar. Específicamente tuve que cambiarlo a [DeploymentItem (@ "Foo / Bar /", @ "Foo / Bar /")] y ahora funciona a las mil maravillas.
No estoy seguro de si esto responde exactamente la pregunta, pero puede ayudar a algunos. Primero, he encontrado que la casilla "Habilitar implementación" debe verificarse para que la implementación funcione. En segundo lugar, el documento dice que la ruta de origen es "relativa a la ruta del proyecto", que al principio tomé como la carpeta del proyecto. De hecho, parece referirse a la carpeta de salida de compilación. Entonces, si tengo una carpeta de proyecto llamada ''TestFiles'' y un archivo llamado Testdata.xml , usar el atributo de esta manera no funciona:
[DeploymentItem(@"TestFiles/Testdata.xml")]
Puedo marcar el archivo Testdata.xml Copy Always , para que la compilación ponga una copia debajo de la carpeta de salida (por ejemplo, Debug/TestFiles/TestData.xml ). El mecanismo de despliegue encontrará entonces la copia del archivo ubicado en esa ruta ( TestFiles/Testdata.xml ) relativa a la salida de compilación. O bien, puedo configurar el atributo de esta manera:
[DeploymentItem(@"..//../TestFiles/Testdata.xml")]
y el mecanismo de despliegue encontrará el archivo original. Así que cualquiera de los dos funciona, pero me he dado cuenta de que al usar Copy Always ocasionalmente encuentro el mismo problema que tengo cuando edito el archivo app.config en un proyecto: si no cambio el código o fuerzo una reconstrucción, nada desencadena la copia de archivos marcado para ser copiado en la compilación.
Para aquellos que prefieren evitar el desorden de DeploymentItem y tomar el enfoque sugerido por @Martin Peck (respuesta aceptada), puede usar el siguiente código para acceder al contenido del recurso incrustado:
public string GetEmbeddedResource(string fullyQulifiedResourceName)
{
var assembly = Assembly.GetExecutingAssembly();
// NOTE resourceName is of the format "Namespace.Class.File.extension";
using (Stream stream = assembly.GetManifestResourceStream(fullyQulifiedResourceName))
using (StreamReader reader = new StreamReader(stream))
{
string result = reader.ReadToEnd();
}
}
Para más detalles, vea este hilo SO
Para ayudar a otros a ayudar: intenté todas las sugerencias aquí y aún así mi elemento de implementación no se estaba copiando.
Lo que tenía que hacer ( como se sugiere aquí ) era agregar un segundo parámetro al atributo DeploymentItem:
[DeploymentItem(@"UnitTestData/TestData.xml", "UnitTestData")]
Para mí, la causa raíz era algo completamente distinto: el código de producción que ejercían mis pruebas era el cambio de nombre y / o eliminación del archivo de prueba .xml que se estaba implementando.
Por lo tanto, cuando ejecutaba mis pruebas de forma individual, pasaban, pero al ejecutarlas todas juntas, la segunda y posterior prueba fallaba con errores de "archivo no encontrado" (que originalmente me diagnosticaron erróneamente como el atributo DeploymentItem no funcionaba) .
Mi solución fue hacer que cada método de prueba individual hiciera una copia del archivo desplegado (usando esta técnica ), y luego hacer que el código de producción que se está probando utilizara el archivo copiado en lugar del original.
Primero tuve deshabilitada la bandera de implementación. Pero incluso después de habilitarlo, por algún motivo desconocido, ni siquiera se copiarían los archivos DLL de destino. Accidentalmente, abrí la ventana de Prueba de ejecución y eliminé todas las ejecuciones anteriores y, por arte de magia, encontré todos los archivos DLL y archivos que necesitaba en la carpeta de prueba en la siguiente ejecución ... Muy confuso.
Pruebe esto para VS2010. Por lo tanto, no necesita agregar DeployItems para cada tif
Eliminar el
[DeploymentItem(@"files/valid/valid_entries.txt")]
[DeploymentItem(@"files/tif/")]
Agregue una configuración de prueba.
- haga clic derecho en el nodo de solución en el explorador de soluciones
- Agregar -> Nuevo elemento ...
- Seleccione el nodo Configuración de prueba a la izquierda, seleccione el elemento a la derecha
- Haz clic en Agregar
Llámalo, por ejemplo, TDD
Elija TDD en TestMenu > Edit Testsettings .
Haga clic en Despliegue. Habilítelo y luego Agregue los archivos y directorios que desee. Habrá una ruta relativa a la solución. Los archivos se pondrán. El archivo original es, por ejemplo, aquí:
D:/Users/Patrik/Documents/Visual Studio 2010/Projects/DCArrDate/WebMVCDCArrDate/Trunk/WebMVCDCArrDate/Authority.xml
Cuando ejecuto mi prueba de unidad, se copia a
D:/Users/Patrik/Documents/Visual Studio 2010/Projects/DCArrDate/WebMVCDCArrDate/Trunk/WebMVCDCArrDate.Tests/bin/Debug/TestResults/Patrik_HERKULES 2011-12-17 18_03_27/Authority.xml
en Testcode lo llamo desde:
[TestMethod()]
public void Read_AuthorityFiles_And_ParseXML_To_Make_Dictonary()
{
string authorityFile = "Authority.xml";
var Xmldoc = XDocument.Load(authorityFile);
No es necesario elegir Copiar siempre; poner los archivos en el proyecto de prueba; agregar rutas codificadas en el código de prueba. Para mí, esta solución funcionó mejor. Intenté con DeploymentItem, copie siempre, pero no fue de mi agrado.
Si ingresa en su archivo .testrunconfig y en la implementación desmarque "Habilitar implementación", las pruebas se ejecutarán en su ubicación normal, y todo funcionará como lo hace al ejecutar la aplicación fuera de una prueba unitaria.
También he enfrentado problemas similares, pero encontré una solución fácil de 3 pasos para esto:
Suponiendo que la estructura de su carpeta se ve así: SolutionFolder/ TestProjectFolder/ SubFolder/
- Vaya a "Elementos de soluciones / Local.testsettings"> "Implementación"> Marque "Activar implementación"
- Si está utilizando VS2010, asegúrese de que los archivos que desea implementar tengan su propiedad "Copiar en la carpeta de salida" establecida en "Copiar siempre" o "Copiar si es más reciente"
- Atribuya su TestMethod con cualquiera de los siguientes:
-
[DeploymentItem(@"TestProjectFolder/SubFolder")]para desplegar todo el contenido de<SubFolder>en el directorio de prueba de ejecución -
[DeploymentItem(@"TestProjectFolder/SubFolder", "TargetFolder")]para implementar todo el contenido de<SubFolder>en<TargetFolder>en el directorio de prueba de ejecución
-
Una nota final sobre MSTest (al menos para VS2010):
Si desea que <TargetFolder> tenga el mismo nombre que el <SubFolder> , el uso de [DeploymentItem(@"SubFolder", @"SubFolder")] fallará silenciosamente cuando el corredor MSTest llegue a un caso tonto. Esta es la razón por la que debe prefijar el <SubFolder> con el <TestProjectFolder> así: [DeploymentItem(@"TestProjectFolder/SubFolder", @"SubFolder")]
También me he enfrentado a problemas similares. Tengo todos los pasos mencionados anteriormente, pero todavía no tengo suerte. Estoy usando VS2010. Luego, descubrí que $ Menú> Prueba> Seleccionar configuración de prueba activa> Rastrear y probar impacto fue seleccionado. Empezó a funcionar después de cambiar Trace y probar el impacto en Local . Esta página contiene información muy útil sobre cómo copiar archivos en la carpeta de resultados de prueba. Siento que debo agregar esta experiencia también.
DeploymentItem es un poco complicado.
Cada archivo en su solución tendrá una configuración de "Copiar a la carpeta de salida" en VS.NET. Necesita esto para ser "Copiar siempre" (o similar) para poder enviar los archivos a la carpeta de salida.
Verifique que tenga este conjunto para los nuevos archivos. Si no tiene este conjunto, los archivos no se copiarán en la carpeta de salida, y luego no se podrán implementar desde la carpeta de salida a la carpeta donde MSTest lo hace.
Personalmente, si tengo los archivos que necesito para las pruebas de mi unidad, he encontrado que insertar esos archivos como recursos en un ensamblaje, y hacer que ese ensamblado se "descomprima" durante las pruebas es una manera más predecible de hacer las cosas. YMMV.
nota: estos comentarios se basan en mi experiencia con VS2010. Los comentarios a mi respuesta sugerirían que este no es un problema con VS2012. Todavía soporto los comentarios de que usar recursos integrados implica menos "magia" y, para mí, hace que la etapa "organizar" de mi unidad sea mucho más explícita.