Nunit: Ejecute métodos de prueba dentro de un dispositivo en paralelo

Actualización: tanto este comentario como el siguiente fueron en respuesta a una persona que aparentemente eliminó sus propios comentarios. Dejo mis respuestas.

Bueno, está en la especificación y está programado para la implementación posterior a 3.0. Si fuera tan fácil, probablemente lo habríamos hecho. No estoy seguro de qué conexión ve con mbunit. El hecho de que lo tuvieran no nos ayuda.

Esto se está volviendo un poco cansado. Algunos puntos, ya mencionados pero aparentemente omitidos ...

1. Hay un plan para implementar lo que está pidiendo.
2. Decidimos como equipo programarlo en un momento determinado.
3. Cuando está programado tiene que ver principalmente con nuestra evaluación del valor de la función en comparación con otras funciones.
4. Hay varias personas en el equipo de NUnit que podrían implementar la función.
5. Podrían implementarlo, dependiendo de las prioridades, fuera de sus cabezas y no necesitarían copiarlo desde ningún lado.

Encuentro su charla sobre "ingeniería inversa" muy inquietante. El código abierto solo es posible en un contexto en el que se respetan los derechos de autor. Entonces, si está sugiriendo que podríamos ignorar los términos de la licencia de mbunit, está fuera de lugar.

Si bien contribuí con muchos parches a MbUnit y lo usé durante años, estaba
nunca un contribuyente clave. No quisiera que mi estado sea tergiversado :)

En cuanto a la ingeniería inversa, aquí no sirve de nada. NUnit funciona
completamente diferente de lo que hizo MbUnit. Llegaremos a este problema a su debido tiempo,
pero lo están abordando con cautela porque otros problemas similares podrían cambiar
la forma en que necesitamos implementar esto o incluso el conflicto.
El 19 de abril de 2015 a las 2:45 a. M., "CharliePoole" [email protected] escribió:

Esto se está volviendo un poco cansado. Algunos puntos, ya mencionados pero
aparentemente se perdió ...

1.

Hay un plan para implementar lo que está pidiendo.
2.

Decidimos como equipo programarlo en un momento determinado.
3.

Cuándo está programado tiene que ver principalmente con nuestra evaluación de la
valor de la característica en comparación con otras características.
4.

Hay varias personas en el equipo de NUnit que podrían implementar el
característica.
5.

Podrían implementarlo, dependiendo de las prioridades, fuera de
sus cabezas y no necesitaría copiarlo desde ningún lado.

Encuentro su charla sobre "ingeniería inversa" muy inquietante. El código abierto es
solo es posible en un contexto en el que se respetan los derechos de autor. Entonces si tu eres
sugiriendo que podríamos ignorar los términos de la licencia de mbunit, estás muy lejos
base.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/nunit/nunit/issues/164#issuecomment -94244650.

¡Un comentario mucho más discreto que el mío!

Nuestras prioridades actuales en el mundo de la ejecución paralela son:

1. Ejecución de procesos paralelos
2. Grupos de exclusión
3. Ejecución del método paralelo (en un dispositivo).

Esto parece representar el orden de mayor utilidad para los usuarios.

También mencionaré que marcar algo como posterior a 3.0 no significa necesariamente que la función llegue más tarde de lo que lo haría si la hiciéramos parte de 3.0. Más bien, puede significar que 3.0 llega en un momento anterior.

Cuando hagamos esto, tendremos que decidir cómo manejar los comandos de instalación y desmontaje. La opción más fácil probablemente sería construir la clase de prueba para cada prueba de modo que no haya disputas por los datos.

De todos modos, preferiría convertir eso en una opción en algún momento, pero no estoy seguro de si es una opción de ejecución o una opción de accesorio por accesorio (atribuido) o ambas.

¡Hola!
La adición de esta función a la próxima versión de NUnit sería genial, ya que es lo único que me impide cambiar a NUnit. ¿Esta función todavía está planeada para 3.4?

@julianhaslinger NUnit 3.4 saldrá a fin de mes, así que no, esta función no se incluirá.

Para su información, este problema está en nuestro hito de Backlog (o pseudo-hito) en lugar de 3.4 porque estamos siguiendo la práctica de agregar solo una pequeña cantidad de problemas de definición clave a cada hito numerado por adelantado.

El próximo hito, 3.6, está programado para caer en 3 meses más, lo que probablemente le suene desalentador. :-( Sin embargo, si ve que este problema se fusiona con el maestro, podrá obtener una caída anterior de nuestro feed MyGet.

@julianhaslinger, esto no estará en 3.4, que probablemente saldrá en poco más de una semana, pero es algo que me gustaría ver hecho pronto, por lo que su voto ayuda: +1:

Además, ¿qué marco de prueba está utilizando que admite la ejecución de métodos paralelos? Pensé que XUnit solo permitía ejecutar pruebas en paralelo hasta el nivel de Clase también. ¿Estoy equivocado? No uso mucho XUnit: smile:

@CharliePoole ¡ Gracias por la respuesta! Ok, esto suena un poco desalentador. Sin embargo, esperaré los próximos lanzamientos (o lanzamientos anteriores). Considere (aún) esta característica en la próxima versión (3.6).

@rprouse Estoy usando MbUnit / Gallio en este momento. El proyecto prácticamente murió y ahora voy a cambiarme a NUnit.

@julianhaslinger ¿Es una cuestión de tiempo de ejecución para ti? ¿Tiene algunos números sobre la distribución de casos de prueba dentro de los accesorios? Lo pregunto porque mi suposición ha sido que la función ofrece poco a los usuarios más allá de lo que obtienen de los dispositivos paralelos. Si eso está mal, podría cambiar su prioridad relativa.

@CharliePoole Exactamente, nuestro problema real es el tiempo de ejecución de los casos de prueba. Nos gustaría usar NUnit para nuestras pruebas automatizadas / de regresión (incluido Selenium / WebDriver) y dado que algunas de nuestras clases de prueba tienen más de 200 casos de prueba, actualmente es un verdadero dolor ejecutar todo el conjunto de pruebas con NUnit.

Las comparaciones (dentro de un conjunto de pruebas más pequeño de nuestras pruebas de regresión) han demostrado que una posible solución NUnit se ejecutará en aproximadamente 1,5 horas, mientras que la solución MBunit actual se ejecutará en 0,5 horas (el mismo conjunto de pruebas).

Sin embargo, @CharliePoole , soy consciente del hecho de que podríamos reducir el tiempo de ejecución dividiendo clases de prueba más grandes en otras más pequeñas, pero esto de alguna manera socavaría la idea inicial de nuestra jerarquía de clases de prueba.

@julianhaslinger : solo para confirmar, ¿está seguro de que el tiempo de ejecución está limitado a la CPU y no a la memoria?

Experimentamos el mismo problema la primera vez que intentamos cambiar a NUnit 3: el tiempo de ejecución se alargó significativamente. Sin embargo, esto se debió a que NUnit maximizó la memoria disponible; hay un problema con la versión actual que retiene todos los objetos de prueba hasta que se completa la ejecución de prueba. Actualmente estamos ejecutando una versión parcheada internamente: quería obtener un PR para 3.4, pero no estoy seguro de tener tiempo en este momento. :-(

Disculpas si no es así, pero pensé que valía la pena mencionarlo, ya que Selenium puede usar su parte justa de memoria. :-)

@ChrisMaddock ¡ Gracias por la entrada! : +1: Lo veremos pronto y luego volveré a usted.

@ChrisMaddock Me encantaría ver su corrección de memoria en 3.4. Si desea poner un PR, podemos ayudarlo a limpiarlo si aún no está listo para la producción: +1:

@rprouse : esta confirmación inicial https://github.com/nunit/nunit/pull/1367/commits/5f98ae51025f7af8244abd4367d1f47260874dfc en PR # 1367 nos libera las cosas correctamente, en un parche v3.0.1.

Verá en el PR que se movió a OneTimeTearDown antes de la fusión; todavía no sé si ese movimiento hizo que no funcionara en v3.2.1, o si hubo otro cambio en funcionamiento que reintrodujo el retención: es posible que no haya vuelto a realizar la prueba después de mudarme.

Intentaremos volver a probarlo y lanzarlo mañana, sería genial para nosotros volver también a las versiones principales. :-)

@ChrisMaddock Eché un vistazo al consumo de memoria durante una prueba de regresión y descubrí que la ejecución de las pruebas no está limitada a la memoria. Supongo que realmente tenemos que esperar una versión de NUnit que pueda manejar la ejecución paralela de métodos individuales dentro de cada clase.

solo para agregar a lo que dijo @julianhaslinger , he visto exactamente el mismo problema al usar NUnit con pruebas de selenio. Tuve que escribir un contenedor personalizado que ejecute instancias individuales de nunit-console.exe contra una sola prueba extraída de un ensamblado aprobado para poder ejecutar pruebas paralelas por ahora. Sin embargo, esto no es ideal porque da como resultado que se generen muchos archivos de salida .xml (uno para cada ejecución de prueba) en lugar de una única salida .xml y también significa que no puedo hacer uso de _OneTimeSetUp_ y métodos de desmontaje y, en su lugar, debo confiar en semáforos externos y variables de entorno para controlar el flujo de ejecución donde solo quiero ejecutar las cosas una vez. He estado siguiendo la promesa de tener una ejecución paralela en NUnit durante mucho tiempo (años) y me decepcionó mucho cómo se implementó la función en 3.0 (solo se admite parcialmente y requiere una investigación real de los problemas y notas de la versión para descubra que no todo fue realmente compatible). Incluso fui tan lejos como para investigar lo que estaría involucrado en hacer avanzar esto yo mismo, pero desafortunadamente parece que el diseño de NUnit está funcionando en contra de la implementación de la ejecución paralela en el nivel del método de prueba, no tengo idea de cómo realmente le gustaría para manejar el potencial de código no seguro para subprocesos (es decir, debe dejarse en manos de la persona que usa NUnit en paralelo para garantizar que todos los métodos de prueba hacen referencia correctamente a cualquier externo de una manera segura para subprocesos o debe NUnit manejar la ejecución de cada método en su propio dominio mientras de alguna manera tratando de ejecutar solo los métodos de configuración y desmontaje de una sola vez) y como ya tengo una solución alternativa, no pude justificar el tiempo para implementar esta función yo mismo (que probablemente sea lo mejor porque me quemaron antes cuando trabajando con equipos en GitHub para ayudarlos a implementar la ejecución paralela). De todos modos ... lo siento por divagar ... Entiendo que la prioridad para las pruebas unitarias del código C # probablemente no dependa tanto del paralelismo a nivel de método, pero por favor sepa eso para aquellos de nosotros que usamos NUnit para pruebas basadas en selenio sería una GRAN mejora. ¡Gracias por adelantado! :sonrisa:

Gracias por tus comentarios. Creo que voy a divagar un poco aquí ...

Ayuda a comprender qué necesitan las personas y por qué lo necesitan. Al no ser un desarrollador web, traté de escuchar a los usuarios de Selenium y concentrarme en lo que querían. Lo que parecía ser eran accesorios paralelos con orden entre los casos de prueba. Entiendo completamente que diferentes personas querrán cosas diferentes, pero cuando ambos grupos se presentan expresando "lo que los usuarios de Selenium necesitan" es un poco confuso. ¿Puede describirme qué tipo de pruebas web podrían querer un paralelismo a nivel de método en lugar de aquellas personas que quieren ejecutar métodos en un orden predefinido? Creo que podría adivinarlo, pero prefiero recibirlo de un usuario.

Con respecto a su solución alternativa ... ¿consideró usar ensamblajes de prueba separados? NUnit estaría encantado de ejecutar cada uno en paralelo en un proceso separado. Por supuesto, eso no elimina la necesidad de sincronizar el acceso a cosas como archivos.

Con respecto a la seguridad de los subprocesos, nunca planeamos que nuestra implementación paralela asumiera la responsabilidad de la seguridad de los subprocesos. Lo único que esperaba garantizar es que NUnit no creará ningún problema de seguridad de subprocesos si sus métodos ya son seguros para subprocesos. Eso en sí mismo resulta no trivial.

Gracias por la respuesta. Entiendo completamente tus comentarios sobre
ordenar la ejecución de la prueba en un accesorio y dividir las pruebas en diferentes
Ensambles.

Ya soy usuario de NUnit y lo he sido durante años (y JUnit antes de eso)
por lo que la idea de confiar en el pedido de pruebas en un accesorio ni siquiera era una
consideración en mi diseño de prueba. Cada prueba intenta ser completamente encapsulada
acción o conjunto de acciones dentro del sitio sin expectativas en el orden de
ejecución. El diseño del sitio que estoy probando también significa que muchas pruebas
puede tardar hasta 20 minutos en ejecutarse (gran parte de este tiempo se dedica a esperar
que suceda en el sitio) y el tipo de prueba cubre
múltiples escenarios similares, por lo que las clases de prueba base se utilizan para reducir el código
duplicación y aumento de la capacidad de mantenimiento mediante el uso de una clase base común
métodos. Las pruebas se organizan en proyectos separados basados ​​en el desarrollo
propiedad del equipo de esa área (por lo que usamos ensamblajes separados, pero hay
hay muchas pruebas por ensamblaje y mi contenedor de prueba manejará la ejecución de
todas las pruebas en todos pasaron en ensamblajes en paralelo como fue creado antes
el primer lanzamiento oficial de NUnit 3 y quería asegurarme de que todas las pruebas tuvieran
el potencial de ser ejecutado simultáneamente con suficientes subprocesos
disponible).

Esencialmente, puede imaginar que un ensamblaje puede tener 10 pruebas y
otras 100 pruebas, pero el ensamblaje con 10 tiene pruebas que duran 10 minutos
cada uno, mientras que el montaje con 100 tiene pruebas que duran 1 minuto cada uno. Si yo
tener una máquina capaz de ejecutar 110 subprocesos paralelos (que en realidad es
parte de nuestro diseño de infraestructura), entonces esperaría que las pruebas terminen
en 10 minutos, no en 100 minutos.

Espero que esto ayude a explicar ... lo siento si las cosas aún no están del todo claras,
pero el punto general es que el paralelismo a nivel de método es algo que he
visto perdido en otras bibliotecas de prueba (prspec en ruby ​​por ejemplo) y cuando
haciendo un análisis de las mejoras de rendimiento que se obtendrán al agregarlo i
descubrió que puede ser un cambio positivo importante. Vea lo siguiente como ejemplo:
https://github.com/bicarbon8/rspec-parallel/wiki/Examples
El 1 de julio de 2016 a las 00:45, "CharliePoole" [email protected] escribió:

Gracias por tus comentarios. Creo que voy a divagar un poco aquí ...

Ayuda a comprender qué necesitan las personas y por qué lo necesitan. No ser un
desarrollador web, intenté escuchar a los usuarios de Selenium y concentrarme en lo que
ellos querían. Lo que parecía ser era accesorios paralelos con pedidos.
entre los casos de prueba. Entiendo completamente que diferentes personas querrán
cosas diferentes, pero cuando ambos grupos se presentan expresando
"Lo que necesitan los usuarios de Selenium" es un poco confuso. ¿Puedes delinearme?
qué tipo de pruebas web podrían querer paralelismo a nivel de método en lugar de
aquellas personas que quieren ejecutar métodos en un orden predefinido? creo que podría
supongo, pero prefiero tenerlo de un usuario.

Con respecto a su solución alternativa ... ¿consideró usar una prueba separada
¿Ensambles? NUnit estaría encantado de ejecutar cada uno en paralelo en un
proceso. Por supuesto, eso no elimina la necesidad de sincronizar el acceso a
cosas como archivos.

Con respecto a la seguridad de los subprocesos, nunca planeamos nuestra implementación paralela
asumir la responsabilidad de la seguridad de los subprocesos. Lo único que esperaba
La garantía es que NUnit no _creará_ ningún problema de seguridad de subprocesos si su
Los métodos ya son seguros para subprocesos. Eso en sí mismo resulta no trivial.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/nunit/nunit/issues/164#issuecomment -229819324, o silenciar
la amenaza
https://github.com/notifications/unsubscribe/ACNsyoczCUV9L7kbF2SHB7lLsyBKlrv9ks5qRFUJgaJpZM4CUZ8r
.

Gracias por la información ... es útil ver una variedad de perspectivas.

Mis 5 centavos.

En nuestro proyecto, tenemos ~ 25 ensamblajes de prueba y la ejecución de pruebas en paralelo por ensamblaje y por dispositivo ya reduce en gran medida el tiempo de ejecución. La ejecución paralela de pruebas dentro del dispositivo lo mejorará aún más. Ahora incluso dividimos la mayoría de los dispositivos que consumen mucho tiempo en varios dispositivos para acelerar la ejecución, pero será mucho mejor si nunit ejecutará pruebas de dispositivos en paralelo.

Lo que realmente quiero ver en nunit es una paralelización de prueba a nivel de caso de prueba, porque dividir tales pruebas en accesorios no siempre es conveniente y conduce a la duplicación de código. Tenemos varias pruebas que pueden tomar hasta varios miles de casos de prueba (la ejecución de cada caso es rápida pero en total toma minutos) o solo docenas de casos (pero cada caso es lento) y por ahora tales pruebas son los principales impedimentos para nosotros.

Gracias por el aporte ... es un área que vamos a abordar en la próxima versión junto con el tema competitivo pero complementario de asegurarnos de que algunas pruebas no se ejecuten en paralelo entre sí.

Mi pregunta anterior era más sobre cómo las personas escriben pruebas, particularmente cuando manejan una aplicación web. Algunas personas insisten en que quieren que cada método sea un paso secuenciado y que el accesorio represente una serie de esos pasos. Por supuesto, esto no es paralelo por definición. Otras personas parecen escribir pruebas muy similares sin secuenciar las pruebas. Supongo que el último grupo escribe métodos de prueba más grandes, con una serie de acciones y afirmaciones en cada uno.

@CharliePoole ¡

En mi opinión, los casos de prueba deben estar aislados y no depender de otros casos de prueba o de la orden de ejecución. Si las personas aún quieren ejecutar algunas pruebas de un solo subproceso, aún pueden usar [Parallelizable (ParallelScope.None)] y / o OrderAttribute.

La implementación de este problema permitirá ejecutar conjuntos de pruebas más rápido en comparación con una cuadrícula de controlador web local o un proveedor de Saas como BrowserStack o SauceLabs. Actualmente trato de limitar la cantidad de métodos de prueba en una clase de prueba a la cantidad de nodos de controlador web o sesiones de navegador disponibles, por lo que la cuadrícula se usa por completo. De lo contrario, si una prueba tiene 8 métodos de prueba y mi grid tiene 8 sesiones de navegador disponibles, solo se usará una porque todos los métodos de prueba de la clase se ejecutarán uno a la vez.

@pablomxnl Absolutamente de acuerdo. Como entrenador o líder de proyecto, siempre he impulsado mucho esa idea. Sin embargo, no estoy usando ninguno de esos sombreros aquí. Soy un proveedor de software con usuarios que piden cosas. Si me piden cosas verdaderamente atroces, simplemente les digo que no. Pero si piden cosas que son razonables en algún contexto, pero no en otros, ni siquiera en la mayoría, lo considero.

En el caso de los sitios web, casi siempre no hablamos de pruebas unitarias. Las pruebas funcionales de nivel superior a menudo requieren secuenciación. Ya sea que se realice mediante un conjunto de pasos en la prueba o una serie de métodos, es un detalle de implementación para nosotros y una cuestión de conveniencia para el usuario. Personalmente, creo que probablemente necesitemos algo llamado [Step] que se encuentre dentro de una clase [StepFixture], o algunos nombres similares, para que podamos alejar todas estas cosas de ordenar / secuenciar de las pruebas unitarias. Quizás tenga tiempo para hacer eso antes de que la web muera. :-)

De todos modos, siempre es interesante saber cómo la gente usa realmente su software.

@CharliePoole , no me malinterpretes preguntando esto (solo quiero estar seguro): ¿Esta función se agregará a la próxima versión (3.5, prevista para el 29 de septiembre de 2016)?

Si bien podría pretender predecir el futuro, eso solo te satisfaría hasta septiembre. :-)

Permítanme responder explicando cómo "programamos" las funciones.

Actualmente estamos probando (desde principios de año) un enfoque que tiene lanzamientos una vez por trimestre. A medida que mejoramos en la liberación, es posible que aumentemos el ritmo. Eventualmente, es posible que podamos realizar una implementación continua.

En un proyecto de código abierto voluntario, no hay una cantidad fija de esfuerzo disponible por mes. Podemos utilizar el enfoque del "tiempo de ayer", pero resulta que la cantidad de tiempo que la gente tiene que dedicar a NUnit, así como la cantidad de personas que se ofrecen como voluntarias, es bastante variable.

Como compromiso, seleccionamos una pequeña cantidad de problemas que son clave para un lanzamiento y los agregamos al hito por adelantado. Mi preferencia es agregar no más del 25% de lo que esperamos lograr. La mayoría de los problemas en una versión solo se agregan a ese hito después de que se terminan o, en el mejor de los casos, cuando alguien se compromete a trabajar en ellos. Por lo general, no encontrará problemas abiertos en nuestro hito 3.5 sin alguien asignado, aunque lo hago ocasionalmente si parece que algo está bloqueando otro trabajo.

Entonces, el lado positivo de lo que hacemos es que prácticamente podemos garantizar que el lanzamiento saldrá a tiempo. El lado negativo es que no podemos decirte qué habrá en él. :-(

Para este problema en particular ... Le he dado alta prioridad para decirles a nuestros desarrolladores que es importante. Alguien tiene que ser libre para trabajar en él y tener suficiente experiencia para un proyecto de este alcance y dificultad. Si alguien con la experiencia adecuada toma esto en cuenta en las próximas semanas, supongo que se puede hacer con el lanzamiento. Como pauta, creo que me tomaría alrededor de un mes, mientras trabajo en algunas otras cosas también, superar esto.

Lo siento, no hay una respuesta más definitiva, ¡pero esa respuesta sería necesariamente una mentira!

@CharliePoole ¿hay alguna actualización considerando esta función?

@tomersss , todavía no hemos empezado a trabajar en esto y esperamos que la versión 3.5 salga en unas pocas semanas, por lo que es poco probable que lo esté en la próxima versión. Nos gustaría ver esta característica agregada pronto, pero hemos estado bastante ocupados esta semana reorganizando nuestros repositorios y base de código. Sin embargo, está marcado como de alta prioridad, por lo que está en nuestro radar.

@CharliePoole, ¿hay alguna actualización de este problema?

@KPKA aún no hemos empezado a trabajar en esto, por lo que no hay ninguna actualización. Para los usuarios con ZenHub instalado, verán que este problema se mueve de Backlog a ToDo y luego en Progress a medida que comenzamos a trabajar en él.

Para los no usuarios de Zenhub, podrá saber cuándo alguien lo recoge observando quién está asignado al problema.

@CharliePoole @rprouse

¡Hola!

¿Hay alguna novedad de acuerdo a este tema?
¿Será en el próximo lanzamiento o si está planeado en uno de los próximos hitos?

Por el momento, este es el único problema que nos impide cambiar a NUnit.
Sería amable si alguien pudiera confesarse a sí mismo para ponerse a trabajar en esto en un futuro cercano, ya que hay muchas personas afectadas, supongo.

Espero escuchar pronto de ti

@GitSIPA ¿qué marco de prueba está utilizando que le permite ejecutar métodos de prueba en paralelo?

Para responder a su pregunta, nadie ha comenzado a trabajar en este tema, por lo que no hay ETA, pero tomaremos en cuenta su voto mientras decidimos en qué trabajar a continuación.

+1, de acuerdo con @GitSIPA. Esta es una funcionalidad realmente importante

@GitSIPA +1
@rprouse Estamos usando mbunit, pero este marco no es compatible ahora. Y tenemos algunos problemas con mbunit.

@rprouse También estamos usando MbUnit en este momento, pero dado que no se brinda soporte para las nuevas versiones de Visual Studio, consideramos cambiar a NUnit.

En el número 1921 @ jnm2 preguntó "¿Qué se interpone entre nosotros y tener casos de prueba parametrizados que se ejecutan en paralelo? ¿Puedo contribuir?"

Segunda pregunta primero: ¡seguro! Nos encantaría tu ayuda.

Y a la primera pregunta:

1. Ejecutamos "WorkItems", que actualmente se asignan uno a uno a las pruebas. Creo que debemos tratar OneTimeSetUp y OneTimeTearDown para un accesorio como WorkItems separados como paso preliminar. El número 1096 trata de esto.

2. Necesitamos tener alguna forma de hacer que un WorkItem dependa de otros WorkItems, de modo que solo esté programado para ejecutarse cuando todos los elementos dependientes de ellos estén completos. Actualmente lo hacemos de una manera muy simplista usando un CountDown, pero necesitamos algo más general. El primer uso de esto, por supuesto, sería que OneTimeTearDown dependiera de la finalización de todas las pruebas. Tendría otros usos más adelante, cuando implementemos la dependencia entre pruebas. Me imagino esto como una cola de elementos de trabajo pendientes, pero puede haber otras formas de implementarlo.

3. Con esas dos cosas fuera del camino, podríamos comenzar a trabajar en el problema principal en sí: programar pruebas para que se ejecuten en lugar de ejecutarlas en el mismo hilo que hizo OneTimeSetUp para el dispositivo.

Si desea trabajar en esto, tendrá que familiarizarse con algunos de los aspectos internos de cómo NUnit realmente envía las pruebas para su ejecución. Estaré encantado de ayudarte a hacer eso.

¿Qué planificación se ha realizado hasta ahora?
Mis necesidades son ejecutar suficientes casos TestCaseSource en paralelo para saturar la CPU. No tengo requisitos de configuración, desmontaje o pedido. Sin embargo, otras personas necesitarán que se tengan en cuenta.

Esperaría que la ejecución de TestCaseSource se paralelice, por lo que dos métodos en el mismo dispositivo que usaron diferentes TestCaseSources ejecutarían las enumeraciones en paralelo. También parece que sería bueno si dos métodos usaran el mismo TestCaseSource si solo se ejecutara una vez, ¿pensamientos sobre esto?

Editar: comentando ESTADO DE LA CARRERA. ¡Ya hemos tenido un buen comienzo! 😆

Repetiré una historia que he tenido que contar mucho últimamente. :sonrisa:

NUnit primero carga las pruebas (también conocidas como descubre, explora) y luego las ejecuta una o más veces, dependiendo del tipo de corredor.

Su TestCaseSource se usa para cargar pruebas, no para ejecutarlas, y ni siquiera lo consideramos como parte de su prueba, aunque puede tenerlo en la misma clase que su prueba.

IOW, sus casos de prueba no "usan" la fuente de su caso de prueba, sino que NUnit usa la fuente para crear los casos de prueba. Por supuesto, no pueden hacer nada hasta que se creen. ¿Tener sentido?

Da la casualidad de que la creación de pruebas desde la fuente se realiza de forma secuencial. Si se está ejecutando algún código en la fuente que lo convierte en un problema, mi primera suposición sería que está haciendo demasiado en la fuente del caso de prueba. Por ejemplo, no desea crear instancias de clases en el origen de su caso de prueba, sino que desea almacenar los parámetros que se usarán para crearlos. Desafortunadamente, esto podría ser todo un capítulo de un libro. :sonrisa:

Entonces, de lo que trata este problema es de __ejecutar__ casos de prueba en paralelo. Eso significa todos los casos de prueba bajo un accesorio, a menos que haya marcado algunos como no paralelizables. En este caso, las pruebas simples no parametrizadas, así como los casos individuales de una prueba parametrizada, se tratarían por igual.

Sería un experimento interesante permitir la paralelización de pruebas en dispositivos donde no hay OneTimeTearDown (creo que OneTimeSetUp está bien). Podría funcionar fácilmente si pudiera hacer esa determinación correctamente. Sin embargo, la determinación es más difícil de lo que podría pensar, porque OneTimeTearDown puede incluir tanto métodos heredados como ActionAttributes globales.

@ jnm2 ¿Ya tuvo la oportunidad de abordar este tema específico?

@julianhaslinger No. Está en mi lista después de mis dos números más inmediatos, 1885 y 1933. Si quieres abordarlo, ¡mucho mejor!

@julianhaslinger Ya que no nos conocemos, por favor discúlpeme por decir que este es un tema difícil de https://github.com/nunit/nunit/issues/164#issuecomment -265267804 para ver un desglose en PR independientes que me gustaría ver para solucionar este problema. Si se le ocurre un enfoque más simple, publíquelo antes de codificarlo, para que podamos sopesar las consideraciones futuras con el YAGNI obvio involucrado en la predicción del futuro.

@CharliePoole @ jnm2 ¡ Hola a todos!

No es que quisiera comenzar a implementar esta función que faltaba, sino simplemente conocer su progreso. Como puedo deducir de sus respuestas (arriba), no ha habido ningún progreso (?) Con respecto a esta solicitud de función en particular.

@CharliePoole Uno de los problemas potenciales que encontré mientras investigaba el código fue cómo se manejan los accesorios en este momento. Actualmente, todos los WorkItems tienen acceso a la misma instancia de Fixture , lo que significa que si los WorkItems se ejecutaran en paralelo, estarían accediendo a una única instancia de la clase de prueba. Esto es problemático debido a las condiciones de carrera que crea cuando las pruebas se basan en Configuración o Desmontaje para establecer campos de nivel de instancia.

Una solución a esto sería hacer que cada WorkItem opere en una nueva instancia de la clase de prueba, pero esto probablemente complicará cómo se comportan las configuraciones de Fixture, ya que ya no habría una sola instancia de la luminaria.

@ chris-smith-zocdoc Sí, esa es la mayor diferencia entre NUnit y su predecesor junit. En el pasado, se discutió ampliamente a favor y en contra, pero ahora no surge mucho. Por esa razón, se suponía que las pruebas de NUnit no tenían estado, y toda la inicialización se realizaba en el método SetUp.

Una vez que se introdujo TestFixtureSetUp (ahora llamado OneTimeSetUp), fue posible realizar una inicialización más cara una vez y hacer que todas las pruebas funcionen con los mismos valores inicializados. Esto es más útil cuando se crean instancias de las clases que se están probando, que pueden ser con estado. En los últimos años, cada vez más usuarios se han valido de esta capacidad.

El tema de agregar una opción para crear una instancia separada del dispositivo de usuario por caso de prueba surge periódicamente. Hasta ahora, no ha llegado a la etapa de ser una función planificada. Definitivamente está relacionado con la usabilidad de una función de método paralelo por parte de los usuarios, pero creo que es ortogonal a la implementación. Si estuviéramos creando un nuevo dispositivo por instancia, simplemente ejecutaríamos "una" configuración de tiempo más de una vez. Por supuesto, eso afectaría mucho a cualquier usuario que esté haciendo uso de estática. 😢

Pospusimos los métodos de prueba en paralelo por dos razones: (1) es difícil de implementar y (2) parecía que los dispositivos en paralelo, aunque más fáciles para nosotros, son suficientes para la mayoría de los usuarios. Muy pocos usuarios parecen compartir el estado en varios dispositivos, mientras que parece (según las discusiones en línea) que muchos usuarios comparten el estado a través de los métodos de prueba. Hasta ahora, muchos usuarios se están aprovechando del paralelismo que existe y, si bien algunos quieren mucho el paralelismo de métodos, parecen ser un grupo relativamente pequeño.

Sin embargo, creo que es hora de hacer algo. Me ocuparé de esto durante el primer trimestre, al menos hasta el punto de ejecutar algunos experimentos y posiblemente llegar a un desglose sensato de las tareas que otros puedan seguir.

Si estuviéramos creando un nuevo dispositivo por instancia, simplemente ejecutaríamos "una" configuración de tiempo más de una vez. Por supuesto, eso afectaría mucho a cualquier usuario que esté haciendo uso de estática.

Creo que es razonable exigir que no haya un estado estático si opta por ejecutar en paralelo, en la medida en que es su culpa si algo se rompe para mezclar el estado estático y el paralelismo. Afortunadamente, todo su código estará bajo prueba, por lo que debería ser difícil pasarlo por alto 😆

Sin embargo, creo que es hora de hacer algo. Me ocuparé de esto durante el primer trimestre, al menos hasta el punto de ejecutar algunos experimentos y posiblemente llegar a un desglose sensato de las tareas que otros puedan seguir.

Cuente conmigo para eso.

¡Yo también!

El sábado 14 de enero de 2017 a las 3:58 a.m., Joseph Musser [email protected]
escribió:

>
>
>
>

[imagen: Boxbe] https://www.boxbe.com/overview

Limpieza automática: mantenga los últimos 1 correos electrónicos ([email protected])

Editar regla
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dwa43L7bW5j4V5ymh5QXh%252FNXk%252F0KVSSFJSqwHw2yu4No%253D%26token%3DjkWoQ96YyOE%252FHA7PvZA8g%252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ%252FKSZ2WZELsWD3YQoDEdjwb%252BWo6wGi4xiUEkGngbggedv8iYBxU7zk% 252FJamyOuVtPzie4dhQJXQkQQ% 252BtolspNKBzqBxtH6H% 252FhqnTQ% 253D% 253D & tc_serial = 28420100882 & tc_randtent = 128339648 & utm_source = stf & utm_no_campana = 00

| Eliminar regla
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dwa43L7bW5j4V5ymh5QXh%252FNXk%252F0KVSSFJSqwHw2yu4No%253D%26token%3DjkWoQ96YyOE%252FHA7PvZA8g%252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ%252FKSZ2WZELsWD3YQoDEdjwb%252BWo6wGi4xiUEkGngbggedv8iYBxU7zk% 252FJamyOuVtPzie4dhQJXQkQQ% 252BtolspNKBzqBxtH6H% 252FhqnTQ% 253D% 253D & tc_serial = 28420100882 & tc_randtent = 128339648 & utm_source = stf & utm_medium_campaña = 00

| Marcar importante
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dwa43L7bW5j4V5ymh5QXh%252FNXk%252F0KVSSFJSqwHw2yu4No%253D%26token%3DjkWoQ96YyOE%252FHA7PvZA8g%252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ%252FKSZ2WZELsWD3YQoDEdjwb%252BWo6wGi4xiUEkGngbggedv8iYBxU7zk% 252FJamyOuVtPzie4dhQJXQkQQ% 252BtolspNKBzqBxtH6H% 252FhqnTQ% 253D% 253D% 26important% 3Dtrue% 26emlId% 3D54854949581 & tc_serial = 28420_randiumCLE2 & tc_serial = 28420_10088m & tc_serial = 28420_randiumCLE2 & tc_serial = 28420_randiumCLE2 & tc_serial = 28420_100882 & tc_serial = 28420_randium =

SI estuviéramos creando un nuevo dispositivo por instancia, simplemente ejecutaríamos "uno"
configuración de tiempo más de una vez. Por supuesto, eso afectaría mucho a cualquier usuario que esté
haciendo uso de la estática.

Creo que es razonable exigir que no haya un estado estático si
optar por ejecutar en paralelo, en la medida en que es su culpa si algo
descansos para mezclar estado estático y paralelismo. Afortunadamente, todo este código
estar bajo prueba, por lo que debería ser difícil pasar por alto: D

Sin embargo, creo que es hora de hacer algo. Voy a asumir esto
durante el primer trimestre, al menos hasta el punto de realizar algunos experimentos
y posiblemente llegar a un desglose sensato de las tareas que otros pueden
darle seguimiento a.

Cuente conmigo para eso.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/nunit/nunit/issues/164#issuecomment-272488655 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAHNVlwVps8pQ93UIwZw6zY7TOyHO0a6ks5rR61EgaJpZM4CUZ8r
.

Al realizar algunas pruebas de cronometraje, descubrí algo interesante. Existe una ambigüedad al llamar a casos de prueba paralelizables. Esto también puede aplicarse a accesorios y otras suites, pero es menos obvio.

Aquí está la cuestión: si un método no es completamente paralelizable, eso significa que no puede ejecutarse en paralelo con __ ningún otro método__. OTOH, si solo no se puede paralelizar dentro de su dispositivo, entonces no se puede ejecutar en paralelo con __ ningún otro método en el mismo dispositivo .__

Propongo que manejemos esta distinción de la siguiente manera:

1. Si un método de prueba no tiene un atributo Parallelizable, debe ejecutarse en el mismo hilo que el dispositivo que lo contiene, siempre que ningún otro atributo (por ejemplo, Apartamento) requiera que se ejecute en un hilo diferente

2. Si tiene un atributo Parallelizable con un alcance de Self, o si una suite de nivel superior especifica un alcance de Children, entonces el método de prueba se ejecuta en paralelo con los otros métodos en el accesorio.

Pensamientos @ nunit / core-team?

Dejado arriba:

1. Si tiene un atributo Parallelizable con un alcance de None, entonces se ejecuta en la cola no paralela.

@CharliePoole : tus tres puntos tienen sentido, aunque no tengo claro cuál sería la alternativa que estás sugiriendo que no hagamos. ¿Podrías aclarar?

Actualmente tratamos no tener un atributo de la misma manera que tener uno con ParallelScope.None. Eso los pone en cola en la cola no paralela si habilito su envío y la ejecución de la prueba se ralentiza significativamente.

PR # 2011 toma algunos pasos iniciales hacia la implementación de esta característica, pero contiene un #define que obliga a los casos de prueba a ejecutarse en el hilo de su dispositivo contenedor. Este comentario documenta lo que creo que se debe hacer para eliminar esa limitación.

Actualmente, OneTimeTearDown de un dispositivo se ejecuta en el hilo que se utilizó para finalizar el último caso de prueba ejecutado. Si los casos de prueba se ejecutan en paralelo, no podemos predecir qué caso de prueba será. Puede ser un hilo con características diferentes a las requeridas para la luminaria. Por ejemplo, si la última prueba en finalizar se está ejecutando en STA, eso es lo que se usará para ejecutar OneTimeTearDown, incluso si OneTimeSetUp se ejecutó en un MTA. En muchos casos, eso podría no causar ningún problema, pero en algunos sí podría.

En realidad, esto también podría ser un problema con los dispositivos de nivel superior, pero la introducción de casos de prueba paralelos significa que habrá muchas más oportunidades para una falta de coincidencia que cause un error.

Por lo tanto, para garantizar que el desmontaje del dispositivo se lleve a cabo en el tipo de hilo correcto, ya no podemos ejecutarlo en el hilo de la última prueba para ejecutar. En cambio, el despachador deberá mantener información sobre todos los desmontajes pendientes y ser notificado para ejecutar esos desmontajes en el hilo adecuado en el momento adecuado. Averiguar cómo hacerlo es la fase de "diseño" de esta función.

para cualquiera que haya estado siguiendo este hilo desde el principio (en 2014) y no quiera o no pueda implementar su propia solución mientras espera la adición de esta función, acabo de encontrar una implementación que usa NUnit 2.6.3 disponible en CodePlex que parece bastante sencillo de usar (he verificado que funciona al ejecutar nuestras pruebas funcionales en múltiples subprocesos paralelos).

http://cpntr.codeplex.com/

disculpas de antemano @CharliePoole si este mensaje es un poco ortogonal a las discusiones recientes en este hilo, pero si alguien más ha estado esperando los últimos 3 años para esta característica adicional basada en las promesas establecidas para NUnit 3 (muy atrás en los primeros días), creo que podría ofrecer una solución hasta que logren resolver los problemas de diseño (parece que se están acercando a la solución).

@CharliePoole

Por lo tanto, para garantizar que el desmontaje del dispositivo se lleve a cabo en el tipo de hilo correcto, ya no podemos ejecutarlo en el hilo de la última prueba para ejecutar. En cambio, el despachador deberá mantener información sobre todos los desmontajes pendientes y ser notificado para ejecutar esos desmontajes en el hilo adecuado en el momento adecuado. Averiguar cómo hacerlo es la fase de "diseño" de esta función.

¿Necesitamos que el despachador sepa de antemano los artículos de desmontaje pendientes o podemos enviarlos a medida que estén disponibles? Más concretamente, donde CompositeWorkItem actualmente llama a PerformOneTimeTearDown, ¿podemos usar el despachador para enviar una nueva unidad de trabajo al turno de trabajo correcto?

@ chris-smith-zocdoc Sí, eso es exactamente lo que estoy haciendo. Creé un nuevo tipo de elemento de trabajo, OneTimeTearDownWorkItem , que está anidado en CompositeWorkItem y se envía cuando se ejecuta la última prueba secundaria. Más adelante, podríamos ver algunas eficiencias cuando OneTimeSetUp y todas las pruebas se hayan ejecutado en el mismo hilo.

No he leído todo con demasiada atención, pero una cosa que me gustaría pedir como parte de esta función es que el paralelismo sea "inteligente", especialmente para las pruebas vinculadas de E / S. Por ejemplo, si tiene 10 subprocesos que ejecutan 100 pruebas paralelizables, no debería ser el caso que los 10 subprocesos se sientan y esperen a que se completen las primeras 10 pruebas antes de pasar a las siguientes 10 pruebas. Si las primeras 10 pruebas comienzan a esperar tareas de E / S de ejecución muy prolongada, los subprocesos deberían tener libertad para pasar a otras pruebas. Cuando se completen las tareas de E / S, los subprocesos reanudarán las pruebas en espera a medida que se liberen los subprocesos.

Básicamente, estoy solicitando una gestión inteligente del rendimiento para las pruebas vinculadas de E / S que hacen un uso extensivo de async / await. Este es nuestro cuello de botella número uno en las pruebas, de lejos.

@ chris-smith-zocdoc De hecho, eso es más o menos lo que estoy haciendo. Básicamente, estoy usando el mecanismo de cuenta regresiva existente para activar el envío de una tarea de desmontaje única. El truco consiste en enviarlo en la cola adecuada.

@gzak Tenga en cuenta que el mecanismo de ejecución en paralelo ya existe. Depende de que los trabajadores realicen tareas de forma independiente en lugar de tener un controlador que las envíe a los trabajadores. Entonces, si un trabajador está ocupado con una tarea por un tiempo, otros trabajadores continuarán ejecutando otras tareas de forma independiente. El truco consiste en establecer el número de trabajadores en función de la naturaleza de las pruebas que se ejecutan. NUnit funciona bastante bien de forma predeterminada con las pruebas unitarias normales vinculadas a la computación, pero otros tipos de pruebas pueden requerir que el usuario establezca un nivel apropiado de paralelismo.

¿Alguien puede explicarme cómo funciona?
Tengo una clase de prueba
Cuando ejecuto las pruebas en esta clase NO en paralelo, todas las pruebas pasaron
Pero cuando los ejecuto con [Parallelizable (ParallelScope.Children)]
Entonces se ejecutan en paralelo (varios métodos en la misma clase)
pero por alguna razón algunas pruebas fallan.
Tengo campos de instancia en esta clase que se usan en las pruebas y parece que esos campos se comparten entre subprocesos
Estoy en lo cierto?
¿Crea solo 1 instancia de esa clase y llama a los métodos simultáneamente en este único objeto?
CharliePoole

¡Lo resolviste! Sí, todas las pruebas de un dispositivo utilizan la misma instancia. Esto es histórico con NUnit, que siempre ha funcionado de esa manera. Debe elegir entre ejecutar los casos de prueba en paralelo y tener cualquier estado que se modifique por prueba. No hay forma de evitarlo actualmente.

Dicho esto, si tiene una proporción decente de dispositivos, simplemente ejecutar dispositivos en paralelo puede brindarle un buen rendimiento.

Es posible tener el [Parallelizable (ParallelScope.Children)] en el
Archivo AssemblyInfo.cs?

¿Alguien lo ha visto funcionar?

El 14 de junio de 2017 a las 01:37, CharliePoole [email protected] escribió:

[imagen: Boxbe] https://www.boxbe.com/overview Limpieza automática: mantenga
últimos 1 correos electrónicos ([email protected]) Editar regla
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk%253D%26token%3D0PvYtf1G2B%252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8%252BJm73uy8ZNUCnQcknlgWKxRQ5zjE%252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF%252FW%252BhysbMtsDw%253D% 253D & tc_serial = 30872123699 & tc_rand = 2087335475 & utm_source = stf & utm_medium = correo electrónico & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001
| Eliminar regla
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk%253D%26token%3D0PvYtf1G2B%252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8%252BJm73uy8ZNUCnQcknlgWKxRQ5zjE%252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF%252FW%252BhysbMtsDw%253D% 253D & tc_serial = 30872123699 & tc_rand = 2087335475 & utm_source = stf & utm_medium = correo electrónico & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001
| Marcar importante
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk%253D%26token%3D0PvYtf1G2B%252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8%252BJm73uy8ZNUCnQcknlgWKxRQ5zjE%252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF%252FW%252BhysbMtsDw%253D% 253D% 26important% 3Dtrue% 26emlId% 3D61187554820 & tc_serial = 30872123699 & tc_rand = 2087335475 & utm_source = stf & utm_medium = email & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001

¡Lo resolviste! Sí, todas las pruebas de un dispositivo utilizan la misma instancia.
Esto es histórico con NUnit, que siempre ha funcionado de esa manera. Usted debe
elegir entre ejecutar los casos de prueba en paralelo y tener cualquier estado que
se modifica por prueba. No hay forma de evitarlo actualmente.

Dicho esto, si tiene una proporción decente de accesorios, simplemente ejecute
Los dispositivos en paralelo pueden ofrecerle un buen rendimiento.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/nunit/nunit/issues/164#issuecomment-308157832 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAHNVuK-J-X74mlAA_eT7OX7dxs7MpoRks5sDqzLgaJpZM4CUZ8r
.

@agray Sí, de hecho, esa es la única razón por la que tengo un AssemblyInfo.cs ahora.

Hola joseph

¿Qué línea de paralelismo está agregando a su archivo AssemblyInfo.cs?

Me encantaría saber qué funciona.

Salud,

Andrés

El miércoles 14 de junio de 2017 a las 4:17 p.m., Joseph Musser [email protected]
escribió:

[imagen: Boxbe] https://www.boxbe.com/overview Limpieza automática: mantenga
últimos 1 correos electrónicos ([email protected]) Editar regla
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DnRGYOf%252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w%253D%26token%3DDcwWzMT9yPtQLckdXD3BLhW5xAB%252BMpc9XdsrbBlwdQJZC%252Bjo3SjsyMVC8vese%252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj%252B2Cfcwg51yUFFQJSwrmTVxqAk4%252BTVGDSrnutdAuqiJ3kTaYQA% 253D% 253D & tc_serial = 30882364582 & tc_rand = 1974513896 & utm_source = stf & utm_medium = correo electrónico & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001
| Eliminar regla
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DnRGYOf%252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w%253D%26token%3DDcwWzMT9yPtQLckdXD3BLhW5xAB%252BMpc9XdsrbBlwdQJZC%252Bjo3SjsyMVC8vese%252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj%252B2Cfcwg51yUFFQJSwrmTVxqAk4%252BTVGDSrnutdAuqiJ3kTaYQA% 253D% 253D & tc_serial = 30882364582 & tc_rand = 1974513896 & utm_source = stf & utm_medium = correo electrónico & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001
| Marcar importante
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DnRGYOf%252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w%253D%26token%3DDcwWzMT9yPtQLckdXD3BLhW5xAB%252BMpc9XdsrbBlwdQJZC%252Bjo3SjsyMVC8vese%252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj%252B2Cfcwg51yUFFQJSwrmTVxqAk4%252BTVGDSrnutdAuqiJ3kTaYQA% 253D% 253D% 26important% 3Dtrue% 26emlId% 3D61214070592 & tc_serial = 30882364582 & tc_rand = 1974513896 & utm_source = stf & utm_medium = email & utm_campaign = ANNO_CLEANUP_EDIT = 001_content

@array https://github.com/array Sí, de hecho esa es la única razón por la que
tener un AssemblyInfo.cs ahora.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/nunit/nunit/issues/164#issuecomment-308325726 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAHNVghNAX8CJkqAy-qhAz8bXNhZcFOQks5sD3NigaJpZM4CUZ8r
.

@agray Sobre el que preguntaste:

c# [Parallelizable(ParallelScope.Children)]

no olvides el objetivo

[assembly: Parallelizable(ParallelScope.Children)]

@LirazShay Utilizo NUnit para impulsar las pruebas de Selenium, y estaba usando campos de nivel de dispositivo para contener cosas como referencias a cuentas de usuario y a la instancia de Selenium WebDriver con la que estaba trabajando y, por lo tanto, no pude ejecutar pruebas en paralelo en el dispositivo. La forma en que trabajé alrededor de eso fue escribir una "fábrica" ​​(uso comillas porque no estoy seguro de que sea el término correcto) que implementa IDisposable que para cada prueba encapsula todas mis necesidades de prueba y las destruye limpiamente al final del prueba sin necesidad de [TearDown] o [OneTimeTearDown] algo así:

 public class TestFactory : IDisposable
    {
    // Instantiate a new SafeHandle instance.
    private readonly System.Runtime.InteropServices.SafeHandle handle = new Microsoft.Win32.SafeHandles.SafeFileHandle(IntPtr.Zero, true);

    // Flag: Has Disposed been called?
    private bool disposed = false;

    public TestFactory()
    {
        this.UserRepository = new List<UserAccount>();
        this.DU = new DataUtility();
    }

    // A list of users created for this test
    public List<UserAccount> UserRepository { get; private set; }

    // A very simple data layer utility that uses Dapper to interact with the database in my application 
    public DataUtility DU { get; private set; }

    // Gets a new user and adds it to the repository
    public UserAccount GetNewUser()
    {
        var ua = new UserAccount();
        this.UserRepository.Add(ua);
        return ua;
    }


    public void Dispose()
    {
        this.Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (this.disposed)
        {
            return;
        }

        if (disposing)
        {
            // Deletes all user accounts created during the test
            foreach (UserAccount ua in this.UserRepository)
            {
                try
                {
                    ua.Delete();
                }
                catch (Exception)
                {
                    // Take no action if delete fails.
                }
            }

            this.DU.DeleteNullLoginFailures(); // Cleans up the database after tests
            Thread.Sleep(1500);
        }

        this.disposed = true;
    }
}

Luego, dentro de una prueba puedo hacer esto:

[TestFixture]
public class UserConfigureTests
{
    [Test]
    public void MyExampleTest()
    {
        using (TestFactory tf = new TestFactory())
        {
            var testUser = tf.GetNewUser();

    tf.DU.DoSomethingInTheDatabase(myParameter);

    // Test actions go here, and when we exit this using block the TestFactory cleans
    // up after itself using the Dispose method which calls whatever cleanup logic you've written into it
        }
    }
}

De esta manera, puedo evitar mucha duplicación de código, y si alguna vez necesito cambiar las dependencias de mi prueba, lo hago una vez en la fábrica. Si alguien tiene comentarios sobre la estrategia que tomé, ¡lo agradecería!

@tparikka Yo mismo recomiendo encarecidamente ese enfoque.

Tengo lo siguiente en mi archivo AssemblyInfo:

[montaje: Parallelizable (ParallelScope.Children)]
[ensamblado: LevelOfParallelism (16)]

¿Necesito el atributo LevelOfParallelism también?

El 15 de junio de 2017 a las 04:37, Joseph Musser [email protected] escribió:

[imagen: Boxbe] https://www.boxbe.com/overview Limpieza automática: mantenga
últimos 1 correos electrónicos ([email protected]) Editar regla
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Doth%252FFbAPG%252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ%253D%26token%3DHe7HfTrm%252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp%252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy%252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A%253D% 253D & tc_serial = 30894750852 & tc_rand = 1847060911 & utm_source = stf & utm_medium = correo electrónico & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001
| Eliminar regla
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Doth%252FFbAPG%252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ%253D%26token%3DHe7HfTrm%252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp%252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy%252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A%253D% 253D & tc_serial = 30894750852 & tc_rand = 1847060911 & utm_source = stf & utm_medium = correo electrónico & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001
| Marcar importante
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Doth%252FFbAPG%252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ%253D%26token%3DHe7HfTrm%252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp%252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy%252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A%253D% 253D% 26important% 3Dtrue% 26emlId% 3D61245244440 & tc_serial = 30894750852 & tc_rand = 1847060911 & utm_source = stf & utm_medium = email & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001

@tparikka https://github.com/tparikka Recomiendo encarecidamente exactamente eso
acercarme.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/nunit/nunit/issues/164#issuecomment-308521058 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAHNVmEzVDbw32Xx0jkYcGK9bZW3tLvXks5sECh8gaJpZM4CUZ8r
.

Todavía no he investigado el uso de LevelOfParallelism . El valor predeterminado es el número de núcleos que tiene.

Si sus pruebas no están vinculadas a la CPU, una mayor tiene sentido. Pero como siempre con perf, la respuesta depende tanto de su escenario que es mejor medir que adivinar.

@CharliePoole Estoy usando TestcaseSource , pero parece que los casos de prueba resultantes no se están ejecutando en paralelo. ¿Se espera que algo como esto funcione?

`` c #
[Accesorio de prueba]
clase deserialización
{
público estático IEnumerableShouldDeserializeAllCases () => Enumerable.Repeat (0, 5) .Select (x => TimeSpan.FromSeconds (2));

    [TestCaseSource("ShouldDeserializeAllCases"), Parallelizable(ParallelScope.Children)]
    public void ShouldDeserializeAll(TimeSpan t)
    {
        Thread.Sleep(t);
        Assert.AreEqual(1, 1);
    }
}

''

El tiempo total empleado es de 10 segundos en lugar de ~ 2.

Pensaré que no hay niños, así que en este caso, es mejor que uses
[Parallelizable (ParallelScope.All)]
o mueva su atributo a nivel de clase.

@ParanoikCZE Gracias. De hecho, estoy volando a ciegas con respecto a lo que significa ese atributo, así que probé todos los valores de enumeración allí. Independientemente de cuál de All , Children , Fixture o Self use, obtengo un tiempo de ejecución de 10 segundos (al menos en Visual Studio).

Intenté moverlo a la clase, pero esto tampoco parece ayudar.

Prueba esto es fuente de inspiración :)

class Deserialization
{
    public static IEnumerable<TestCaseData> ShouldDeserializeAllCases
    {
        get
        {
            for (int i = 1; i <= 5; i++)
                yield return new TestCaseData(TimeSpan.FromSeconds(i)).SetName($"Thread_worker_{i}");
        }
    }

    [TestCaseSource(nameof(ShouldDeserializeAllCases)), Parallelizable(ParallelScope.Children)]
    public void ShouldDeserializeAll(TimeSpan t) => System.Threading.Thread.Sleep(t);
}

@ParanoikCZE Gracias de nuevo. Probé esto en Visual Studio y la visualización es mucho más clara, pero las pruebas aún se ejecutan secuencialmente. Es más fácil ver esto si usa un sueño constante para cada caso de prueba en lugar de aumentar los pasos.

Intente agregar [assembly: LevelOfParallelism (5)] en AssemblyInfo, creo que hay algún valor predeterminado, pero tal vez no funcione para usted de alguna manera. De todos modos, no tengo ideas. :)