5

Usamos archivos .resx para internacionalizar nuestra aplicación en varios idiomas. Nuestras pruebas unitarias automatizadas están en su propia asamblea, y que corren mstest en ese proyecto desde la línea de comandos desde dentro de nuestro IC (Jenkins) así:Con mstest, ¿puedo ejecutar mi conjunto de pruebas de unidad con cada uno de los idiomas compatibles?

MSTest.exe /testcontainer:unittests.dll/categoría:" ! TemporaryExclude" /resultsfile:UnitTests.trx

Hemos encontrado casos en los que las pruebas unitarias particulares fallarían si se ejecuta en una máquina establece en una de nuestras culturas compatibles no están en inglés. Quisiéramos que nuestro CI ejecute las pruebas unitarias en cada cultura, incluida la actual en-us. Este debe ser un problema que otras personas se han topado, pero no he encontrado nada en él.

¿Hay alguna manera de ejecutar mstest contra una cultura específica? no vi nada en the command-line docs for mstest.exe

Yo sé que podría especificar el Thread.CurrentThread.CurrentCulture y Thread.CurrentThread.CurrentUICulture en mis pruebas, pero no quiero desarrolladores en nuestro equipo tengan que contra copias pegar duplicados de sus pruebas, uno por cultivo. Sería trabajo extra para ellos y tener duplicados diferentes solo por cultura sería difícil de mantener y propenso a errores.

me preguntaba sobre la derivación de una clase a partir de TestMethodAttribute y tener que pasar por todas mis archivos DLL de recursos de idiomas, que ejecuta el código de prueba una vez para cada uno, pero Visual Studio me dice:

error 2 'ClassToExtendTestMethodAttribute': no se puede derivar de tipo cerrado 'Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute'

Lo mismo para TestClassAttribute.

Respuesta

3

Una idea podría ser leer la cultura de un archivo de configuración en el método TestInitialize para usar con Thread.CurrentThread.CurrentCulture, y poner este método en una clase de prueba de unidad base (que todas las demás clases de prueba deberían derivar). Si esto funciona bien, puede llamar al mstest desde un archivo por lotes en un bucle y cambiar el archivo de configuración (desde "en-us" a "fr-FR" por ejemplo) después de cada paso.

Como alternativa, aquí hay un puntero a un "Unit Test Extensibility Sample" que no he usado, pero podría ayudarlo.

+0

+1 ¡Gran idea! Prefiero no hacer lo mismo con el acceso al archivo antes de ejecutar cada prueba (dada la cantidad de pruebas que tenemos), así que voy a probar ClassInitialize en lugar de TestInitialize. Si lo hago funcionar, aún aceptaré tu respuesta. – JeffH

+0

@heginy Parece que las clases derivadas no ejecutan ClassInitialize de sus padres a menos que lo llamen explícitamente desde un método ClassInitialize propio. Las clases derivadas * do * ejecutan TestInitialize de sus padres, por lo que podría hacer que tu técnica funcione de esa manera. Como dije, no estaría encantado de hacer que todas las pruebas se envíen al sistema de archivos. Probablemente elegiré la técnica ClassInitialize, aunque hay un paso adicional además de la subclasificación. Aceptando tu respuesta. ¡Gracias! – JeffH

+0

@JeffH Genial, me alegro de que funcionó. Tiene razón sobre el acceso al archivo cada vez. Si puede resolverlo con ClassInitialize, quizás AssemblyInitialize también podría funcionar. – henginy

Cuestiones relacionadas