unit-testing - unitarias - visual studio 2017 unit test project
Proyecto innecesario se reconstruye cuando la prueba de unidad en Visual Studio (3)
Compruebe qué versión de Visual Studio 2013 está utilizando. La actualización 1 tiene un problema bastante grande donde reconstruye todo. Consulte: https://connect.microsoft.com/VisualStudio/feedback/details/811112/unnecessary-solution-rebuild-on-each-test-run
Actualizar a la Actualización 3 hizo el truco!
No estoy seguro si Resharper podría afectar las cosas también. Sugiero desinstalarlo temporalmente.
Conozco this pregunta (y sus respuestas), pero a pesar de haber probado todas las opciones sugeridas, todavía estoy atascado.
Tengo una solución con varios proyectos, pero para este caso en particular, digamos que tengo mi ExampleProjectA y un proyecto de prueba de unidad correspondiente ExampleProjectATest . La primera se agrega como una referencia al proyecto de prueba, no a través de las "Project References" Visual Studio, sino como un enlace a la DLL (algo como "../Path/$(Config)/ExampleProjectA.dll" ) - esto es debido a los requisitos del servidor de compilación en nuestra empresa, pero el problema también existía cuando todavía teníamos "Project References" .
- Construir y luego ejecutar una prueba de una sola unidad funciona bien
- Cambiar solo una letra en una prueba de unidad y luego dejar que la prueba se ejecute siempre genera una reconstrucción de
ExampleProjectA, aunque esto no sea necesario - La configuración de todos (solo hubo unos pocos) archivos en
ExampleProjectAdesde "Copiar siempre" a "Copiar si es más nuevo" en sus respectivas propiedades no ayudó - Marcar la casilla de verificación en
Tools => Options => Projects and Solutions => Build an Run(ver más abajo) tampoco cambió nada
Para ver si había más información disponible, cambié la configuración de salida de compilación a diagnóstico. Cada vez que se desencadena una reconstrucción de ExampleProjectA , la primera línea en la ventana de salida es
1> El proyecto ''ExampleProjectATest'' no está actualizado. El archivo de entrada ''c: / tfs / mysolution-dev / exampleprojectatest / myfolder / namegeneratortest.cs'' se modifica después del archivo de salida ''C: / tfs / mysolution-dev / exampleprojectatest / bin / Release / exampleprojectatest.pdb''.
El nombre de la clase escrito en la ventana (por ejemplo, namegeneratortest.cs ) cambia según el archivo de prueba que namegeneratortest.cs .
No estoy seguro de por qué aparece este mensaje, pero el siguiente paso fue deshabilitar la información de depuración como se muestra a continuación en Project properties => Build => Advanced => Output => Debug Info => None :
Sigue igual, nada ha cambiado.
Otra cosa que intenté fue verificar las marcas de tiempo de los archivos contenidos en mi carpeta de soluciones (ya que hubo un caso en el que un usuario tenía un archivo con una marca de tiempo futura; consulte la publicación vinculada), sin éxito.
Lo último que intenté fue cambiar la configuración de compilación en el Configuration Manager a una plataforma de destino diferente: algunas configuraciones no me permitían construir la solución con éxito, otras configuraciones sí, pero el problema descrito persistía, por lo que no hubo cambios.
El comportamiento es similar (aunque no es el mismo) con Visual Studio Test Runner y el proporcionado por ReSharper.
Visual Studio Test Runner
El proyecto ''ExampleProject'' no está actualizado. El archivo de entrada ''C: / tfs / mysolution-dev / exampleprojecta / Views / Shared / someview.cshtml'' se modifica después del archivo de salida ''C: / tfs / mysolution-dev / exampleprojecta / bin / exampleprojecta.pdb''.
ReSharper Test Runner
El proyecto ''ExampleProjectATest'' no está actualizado. El archivo de entrada ''c: / tfs / mysolution-dev / exampleprojectatest / myfolder / namegeneratortest.cs'' se modifica después del archivo de salida ''C: / tfs / mysolution-dev / exampleprojectatest / bin / Release / exampleprojectatest.pdb''.
Estoy usando Visual Studio 2013 Premium Edition con ReSharper 8.2 y las últimas actualizaciones, los proyectos en nuestro archivo de solución están en C #.
Actualizar
Para aclarar, la primera línea en la ventana de resultados muestra que el proyecto de prueba debe ser reconstruido, esto está bien. Las siguientes líneas, sin embargo, indican que también se debe reconstruir ExampleProjectA , lo que no debería ser necesario. Los mensajes subsiguientes a la ventana de resultados también muestran que otros proyectos (a los que se hace referencia desde ExampleProjectA deben reconstruirse).
Actualización 2
A pesar de instalar la Actualización 4, nada ha cambiado.
En mi caso, la solución fue cambiar la acción de compilación de un archivo de configuración de "Copiar siempre" a "Copiar si es más nuevo". Tomó un tiempo encontrarlo, ya que tuve que cambiar los detalles de salida de la compilación para obtener los detalles sobre qué archivo estaba causando el error, por ejemplo
Project ''xyz'' is not up to date. Project item ''c:/my/path/web.config.dev'' has ''Copy to Output Directory'' attribute set to ''Copy always''.
Según mi experiencia, también puede suceder que se muestren diferentes nombres de archivos al compilar varias veces, así que asegúrese de tener el correcto y / o compile nuevamente si el problema persiste.
También eche un vistazo a esta pregunta y sus respuestas para encontrar más información.
He resuelto este problema al eliminar el archivo .pdb en la carpeta / obj. Parece que Visual Studio está verificando la hora de modificación del archivo para decidir si debe compilar o no el proyecto (en su caso ExampleProjectA ) y el .cshtml es más nuevo que el pdb. Pero al iniciar la compilación, los cambios de proyecto en los archivos .cshtml no están activando la reconstrucción de .pdb, por lo que el problema persiste.
Al eliminar el .pdb en la carpeta / obj (no en / bin, ya que el archivo se copia desde / obj y mantendría la hora de modificación anterior) el tiempo de modificación para el .pdb es más nuevo que el .cshtml y el VS no Necesidad de construir el proyecto antes de ejecutar las pruebas. Por supuesto, esto solo funciona hasta la próxima vez que modifique un archivo .cshtml, por eso lo califico como una solución.