visual studio - Resharper 7: MSTest no funciona-"La prueba no se ejecutó"

visual-studio visual-studio-2012 (18)

Desde que actualicé a VS2012 y Resharper 7, mis Pruebas de MS que ya funcionaban ya no se están ejecutando.

Las pruebas se ejecutan en un entorno ASP.NET. Yo uso los siguientes Atributos:

[TestMethod] [HostType("ASP.NET")] [AspNetDevelopmentServerHost("C://Projekte//****//Website", "/")] [UrlToTest("http://localhost:7924/")]

¿Algúna idea de cómo arreglar esto?

Compruebe que las referencias que tenga en el proyecto de prueba estén configuradas en Copiar local verdadero.

Descubrí que el archivo de configuración para la prueba unitaria puede necesitar una comprobación de a cuál apunta ReSharper. Tuve el mismo problema y fue por las pruebas de mi unidad para el arnés RS que apuntaba al archivo equivocado.

En VS2012, el Proyecto de prueba no funciona en Carpetas compartidas como / XXXXXX / XXX Lo resolví copiando el Proyecto de prueba en dispositivos locales. Buena suerte

En mi caso, era el NUnitTestAdapter nuget el que debía eliminarse.

Intente ejecutar las Pruebas Unitarias usando el Explorador de Pruebas MSTest. Puede encontrar más detalles en la ventana de salida de la causa raíz.

Para mí, era un conjunto referenciado que usaba una versión más reciente de NUnit que la que se hizo referencia en el proyecto de prueba. Usar la misma versión actualizada solucionó el problema.

System.IO.FileLoadException: No se pudo cargar el archivo o ensamblado ''nunit.framework, Version = 2.6.3.13283, Culture = neutral, PublicKeyToken = 96d09a1eb7f44a77'' o una de sus dependencias. La definición del manifiesto del ensamblaje ubicado no coincide con la referencia de ensamblaje.

Otro (tonto) problema podría ser; Accidentalmente tuve el proyecto configurado para no construir. Vaya a Build / "Configuration Manager" y asegúrese de que el proyecto esté configurado para compilar.

Seguí recibiendo "Prueba no se ejecutó" en Resharper. Probé todas las recomendaciones, pero nada funcionó. Lo que me solucionó fue ejecutar Visual Studio como administrador. (VS2013 con Resharper 8.1)

Solo para agregar a esto, escribí sobre mi archivo app.config con uno nuevo que me faltaban algunas secciones que necesitaba. Volví a agregar las secciones, y en ese momento obtuve el mismo error en el reafilado. Gracias a los comentarios anteriores, lo comparé con una versión anterior y descubrí que me faltaban los nombres de las secciones en las secciones config.

Solo un extracto de MSDN con respecto a Assert.Inconclusive :

El código generado por Visual Studio al crear pruebas unitarias incluye una declaración no concluyente como marcador de posición.

Ocurre si algo está mal con la solución, la más frecuente es una configuración incorrecta, como espacios de nombres incorrectos o no coincidentes, objetivos de compilación inconsistentes, etc., lo que lleva al hecho de que UnitTestExplorer no puede usar las pruebas de unidad proporcionadas adecuadamente. Entonces, la solución general es verificar los últimos cambios y corregir los errores.

Tan extraño como es, usando VS2012, usando Resharper 8.0, usando NUnit, recibí este error debido a una entrada en mi archivo app.config. Agregué una cadena de conexión EntityFramework y este comportamiento comenzó. La eliminación de toda la sección de cadenas de conexión muestra que el corredor de prueba comienza / funciona nuevamente. La salida de visualización muestra que app.config no es válido: esto causaba este comportamiento específico en el corredor de prueba: "La prueba no se ejecutó".

Tuve el mismo problema en C #: las pruebas unitarias ejecutadas por ReSharper simplemente se detuvieron con "La prueba no se ejecutó". Ninguna otra información

Resultó ser debido a mi sección personalizada en App.Config. Quitando eso y funcionó.

Configuración: Visual Studio C # 12, ReSharper 8.2.3

Tuve el mismo problema porque el nombre de la clase de prueba tenía los caracteres ''<'' y ''>'' en él (también ''('' y '')'' causó este problema).
Eliminar esos símbolos solucionó el problema.

Podría usar símbolos en los identificadores gracias al soporte Unicode de F #.

Tuve el proyecto de prueba establecido en AnyCPU y el proyecto se estableció explícitamente en x86 cuando esto sucedió. Configurar el proyecto de prueba a x86 me lo resolvió.

Estoy usando VS2012 R # 8 y nUnit

Tuve exactamente el mismo problema y nada me ayudó.

eventualmente vi que tenía un desajuste en mis espacios de nombres del proyecto de unidad y el proyecto de prueba de unidad.

El espacio de nombres de mi proyecto de unidad es unit.project y el proyecto de prueba se llamó unit.project.tests, pero el espacio de nombres predeterminado de la prueba era el mismo que el de la unidad, ambos eran unit.project.

Una vez que he actualizado los espacios de nombres para que sean diferentes (un espacio de nombres para cada proyecto) ¡todo funcionó!

Tuve un problema similar con la prueba NUnit , que no se ejecutaría, pero R# solo los marcaría como "No se ejecutó la prueba".

Al ejecutarlos con el corredor nativo de NUnit , se reveló que el archivo app.config tenía un error (en realidad, 2 secciones de ConnectionString). Reparar esto también hizo que las pruebas se ejecutaran en R# corredor de prueba R# .

Usando VS2010 y ReSharper 9.1, el problema era que LocalTestRun.testrunconfig el archivo LocalTestRun.testrunconfig pero se hacía referencia en mi archivo .vsmdi .

La prueba sin VS se ejecutaba correctamente, pero siempre tuve el error "La prueba no se ejecutó" en la interfaz de usuario de la prueba ReSharper.

Así que simplemente LocalTestRun.testrunconfig mi antiguo archivo LocalTestRun.testrunconfig y todo se ejecutó perfectamente.

Probablemente podría haber actualizado mi archivo .vsmdi para no hacer referencia al archivo perdido ... No .vsmdi eso.

Yo mismo problema, solo ..

Cambió el modificador de acceso a métodos de privado a público.
Se eliminó la palabra clave estática de los métodos.

Eso es. Funcionó para mí Pero eso es para C #.

Yo tuve el mismo problema. No se pudo hacer funcionar el corrector de prueba de Visual Studio, así que intenté depurar una prueba. Esto lanzó una excepción ConfigurationErrorsException, que no tenía mucho de un rastro de pila pero contenía la frase "ClientSettingProvider". Busqué en mi solución y encontré que algo había agregado una clave appSetting para "ClientSettingProvider.ServiceUri" a mi app.config. Eliminé esto (junto con un elemento connectionStrings vacío) y reconstruí todo: ¡solucioné el problema!

Revisa tu app.config e intenta eliminar cualquier elemento vacío o cualquier cosa que parezca sospechosa.