Nunit: Proyecto o ensamblado independiente de AssertionHelper

Ni siquiera sabía que teníamos un AssertionHelper: temeroso:

Lo tomo como un voto a favor de la remoción. :-)

Tampoco supe que teníamos uno :(

¿Qué hace o qué se supone que debe hacer?

Su clase de prueba hereda de ella, lo que le brinda una sintaxis para las afirmaciones que no requiere un nombre de clase estático. Consulte, por ejemplo, https://github.com/nunit/nunit-csharp-samples/blob/master/syntax/AssertSyntaxTests.cs y busque "Expect"

Como comenté en el n. ° 1211, no se ha actualizado con las últimas funciones de Assert. Esa sintaxis. Idealmente, si lo conservamos, creo que debería dividirse en un proyecto separado y ser mantenido por personas que realmente lo usan.

Como comenté en el n. ° 1211, no se ha actualizado con las últimas funciones de Assert. Esa sintaxis. Idealmente, si lo conservamos, creo que debería dividirse en un proyecto separado y ser mantenido por personas que realmente lo usan.

Estoy de acuerdo. ¿De cuántas formas queremos apoyar la escritura afirma? Mantener Assume sincronizado con Assert es bastante difícil: sonríe:

En muchos casos, creo que puede usar "using static nunit.framework.Assert". Así que no me importa si fue eliminado.

De acuerdo con lo anterior, tampoco sabía que existía.
Quítelo o sáquelo solo para mantenerlo a salvo.

¿Podríamos extraer el ayudante en un paquete nuget; simplemente cree uno manualmente por ahora, ya que es una especie de sonda, y luego ver cuántos lo descargarían?
Si se obtiene, digamos menos de 1000 durante un período de 6 meses, entonces lo descartamos.

Lo uso con frecuencia en mis proyectos, pero estoy firmemente a favor de eliminarlo gradualmente de NUnit (ya sea eliminándolo por completo o moviéndolo a un paquete subsidiario). Puedo refactorizar fácilmente mis proyectos para prescindir de él; son solo un par de buscar y reemplazar para Expect (y el compilador se encargará del resto de errores de marcado cuando corresponda).

Parece una característica. :-)

Podríamos hacer esto de una manera ad hoc, pero me gustaría usarlo como piloto para algo que estaba en el diseño original de NUnit 3. Existía la idea de que se podían colocar sintaxis adicionales en la parte superior del ensamblaje del marco. Este es bastante sencillo y podríamos usarlo para crear un diseño para sintaxis alternativas agregadas a NUnit. Eso significaría que se convertiría en un proyecto y descarga por separado, como sugiere Terje.

En sí misma, esta es una característica de baja prioridad, pero podríamos impulsarla para romper el diseño necesario para superponer el marco. Debería ser bastante sencillo de hacer.

@ MSK61 Alternativamente, ¿está interesado en ayudar a mantenerlo si lo cambiamos a un paquete separado?

PR # 1250 ahora ha aislado el uso de AssertionHelper dentro de nuestras propias pruebas. Ya no se usa en absoluto excepto en AssertionHelperTests. Esto nos permite separarlo o eliminarlo fácilmente.

He marcado este problema como 'diseño de estado' ya que tenemos que decidir realmente qué queremos hacer antes de continuar. Aquí está mi opinión ...

No creo que debamos eliminarlo porque al menos algunas personas lo usan. El hecho de que sea un número pequeño no me importa tanto. Pasamos a 3.0 sin decidirnos por esto como un cambio importante, por lo que diría que es demasiado tarde para hacerlo ahora. NUnit tiene una larga tradición de continuar apoyando a los usuarios mucho más allá de lo que hacen la mayoría de los proyectos comerciales. Me gustaría mantener la tradición.

Además, creo que decidir cómo manejar AssertionHelper es algo útil para nosotros. El diseño de NUnit 3.0 originalmente requería capas sintácticas alternativas en la parte superior del núcleo del marco. Dejamos eso a un lado para el lanzamiento inicial, pero me gustaría volver al tema. AssertionHelper es relativamente trivial (dos archivos más un archivo de prueba) y podemos concentrarnos en la arquitectura deseada para las interfaces sintácticas como parte de esto.

[En caso de que no haya visto los documentos de diseño por un tiempo, los adaptadores sintácticos para el marco estaban destinados a servir para dos propósitos: sintaxis alternativas para usar NUnit y interfaces de lenguaje alternativo. Las aplicaciones de terceros existentes en cada categoría son shouldly y fsunit. Planeamos proporcionar una forma estándar para crear adaptadores de sintaxis sobre el marco, usarlo nosotros mismos y ofrecerlo a desarrolladores externos como una forma de fomentar el uso de NUnit. Como se indicó anteriormente, este fue un desafío demasiado grande para entrar en 3.0, por lo que no lo hemos implementado].

Volver a AssertionHelper ... aquí hay algunas opciones ...

• Mantenlo como parte de NUnit
  
  
  
  • Espacio de nombres separado (no me gusta esto porque rompe la compatibilidad)
  
  
  • Ensamblaje separado
  
  
• Hacer un nuevo repositorio
  
  
  
  • Solo código fuente: la gente puede incluirlo en sus propios proyectos
  
  
  • Distribuir binarios
  
  
  • Haz ambas cosas (similar a lo que hace fsUnit, esta es la opción que más me gusta)
  
  

Si nuestra dirección incluye la distribución de binarios, tenemos que decidir qué compilaciones admitir. Podrían ser todas nuestras compilaciones existentes, por supuesto, pero estaría de acuerdo con limitarlo a .NET 4.5 y Portable. Podríamos agregar más si hubiera una demanda. Los usuarios nunca nos dicen si hacemos demasiado, pero suelen hablar si hacemos muy poco. :-)

Preferiría pasar al uso de configuraciones separadas en lugar de proyectos separados para cada tipo de construcción. Eso limitaría la cantidad de proyectos que tenemos que definir y podríamos usar la compilación condicional según sea necesario. AssertionHelper incluye algunas características que deben excluirse en la compilación Portable.

Por favor agregue sus comentarios aquí. Cuando parezca que tenemos un consenso, seguiré adelante.

Esta parece una excelente manera de "desaprobar" la funcionalidad, moviéndola a un repositorio separado y paquetes de complementos. Entonces, es claramente una preocupación de mantenimiento separada y se puede actualizar solo cuando se solicitan específicamente nuevas funciones. (Lo cual, basado en este tema, ¡puede ser raro!) También sería significativamente más fácil de romper que las otras compilaciones de framework que están en la lista, lo que podría crear problemas de mantenimiento.

Para revitalizar la discusión ...

Creo que un paquete de repositorio, ensamblado y nuget por separado suena ideal. Requeriría una nueva referencia de proyecto para los usuarios ('cambio importante'), pero parece aceptable, solo similar a lo que se acaba de requerir para .NET 2.0 con NUnit.Linq.

Espacio de nombres separado (no me gusta esto porque rompe la compatibilidad)

Estuve de acuerdo en que se debe mantener el espacio de nombres actual, lo cual es una pena si va a ser un complemento, ¡pero los problemas de compatibilidad superarían la 'fealdad' en mi opinión!

Podrían ser todas nuestras compilaciones existentes, por supuesto, pero estaría de acuerdo con limitarlo a .NET 4.5 y Portable.

Para la funcionalidad 'heredada', ¿quizás tendría sentido incluir / solo los objetivos más antiguos?

Preferiría pasar al uso de configuraciones separadas en lugar de proyectos separados para cada tipo de construcción. Eso limitaría la cantidad de proyectos que tenemos que definir y podríamos usar la compilación condicional según sea necesario. AssertionHelper incluye algunas características que deben excluirse en la compilación Portable.

Supongo que con esto te refieres a un solo proyecto VS y, en su lugar, lo apuntas a diferentes tiempos de ejecución en tiempo de compilación, es decir, ¿a través de Cake? Si es así, estoy de acuerdo.

¿No seguirá esto estrechamente acoplado al marco debido a su necesidad de las diversas afirmaciones bajo las sábanas? Si ese es el caso, entonces un ensamblado separado se vincularía a una versión específica del marco y tendría que publicarse en sincronía. Si ese es el caso, ¿no es más fácil dejarlo donde está?

Supuse que tendría que haber algo equivalente a nunit.engine.api a nivel de marco. No estaba seguro de si esa era la idea del "adaptador sintáctico" a la que se refería @CharliePoole .

(¡No tengo mucha visión general del código aquí en cuanto a lo posible que realmente es!)

Estoy seguro de que podemos resolverlo con algún tipo de indirección como el motor
usos, me pregunto si vale la pena el esfuerzo :-)

Bueno, es de baja prioridad, por lo que no vale la pena un montón de esfuerzo. :-) Algo a considerar cuando decidimos cómo hacerlo.

@ChrisMaddock He estado usando prioridades de manera ligeramente diferente para problemas que son parte de Epics. Marco aquellos bajos que pueden terminar siendo opcionales en lo que respecta al Epic.

@rprouse Creo que es posible algún tipo de indirección, pero eso lo haría dependiente de una refactorización mucho más ambiciosa del marco, similar a lo que han hecho los chicos de xunit. He pensado en eso, pero no he creado un problema más allá de separar las afirmaciones. Quizás sea material 4.0. :-)

@ChrisMaddock Sí ... Estaba sugiriendo que tengamos configuraciones como "Portable - Debug", "Desktop - Release", etc. O tal vez podríamos usar las nuevas definiciones de netstandard en su lugar.

Para una tarea de bajo precio como esta, mi primera opción sería dejarla reposar por un tiempo. Mi segunda opción, si alguien se muere por intentarlo, sería hacer un ensamblaje separado dentro de la solución existente. Pero realmente, prefiero verlo esperar hasta que se complete la epopeya.

@rprouse Iba a publicar mi orden propuesto para hacer los sub-temas en el Epic pero estaba esperando sus comentarios al respecto primero. ¿Debo seguir adelante y publicar?

@CharliePoole sigue adelante y publica. Hemos hablado de ello lo suficiente como para que ambos estemos en la misma página.

Mirando hacia atrás en esto después de una larga ausencia, aquí están mis pensamientos actuales ...

1. Deberíamos __realmente__ deshacernos de esto. Ofrece una forma alternativa de hacer afirmaciones, pero no reemplaza a Assume o Warn, por lo que es una implementación parcial, que no queremos completar.

2. Es posible que mis preocupaciones sobre el cambio del espacio de nombres no hayan sido justificadas. Dado que solo puede usar esto heredando de AssertionHelper, realmente solo necesita cambiar la línea de declaración para su clase de prueba.

3. Necesitamos decidir si queremos mover esto gradualmente o en un gran cambio. ¿Es mejor para los usuarios sufrir múltiples cambios o solo un cambio, aunque sea un poco más grande?

Un gran cambio suena bien.

¿Seguía considerando un paquete separado, al menos para algunas versiones, para ver cómo es el uso?

Agregué esto nuevamente a la lista de trabajos pendientes ya que solo lo estamos marcando como obsoleto por ahora.

Si seguimos adelante y eliminamos esto, los repositorios de muestras también deberán actualizarse. Usan AssertionHelper.

Podemos hacerlo de antemano. Agregué problemas para C #, C ++ y VB. Las muestras de F # no lo usan.

Dejando mi 2c aquí:

Yo, por mi parte, soy un gran admirador de la sintaxis Expect proporcionada por AssertionHelper, especialmente cuando uno tiene que lidiar con proyectos de Javascript junto con los de .NET y la sintaxis sigue siendo familiar entre los dos.

Parece que el interés en AssertionHelper es el reino de lo esotérico, por lo que me ofrezco como voluntario para ser parte del mantenimiento de AssertionHelper si se va a publicar como un repositorio separado. Una idea sería lanzar también paquetes nuget con la misma versión (es decir, nunit xyz tiene un nunit.assertionhelper xyz correspondiente que depende específicamente de nunit xyz) en paralelo con las versiones nunit. Una vez más, me ofrezco como voluntario para ser parte de esto.

Una idea también podría ser proporcionar Expect como estática que se puede importar estáticamente, de modo que los dispositivos de prueba no tengan que heredar de AssertionHelper, lo que hace que algunos otros escenarios sean más fáciles de manejar. De hecho, esto me suena (a mí) como una forma relativamente limpia de hacer la ruptura. ¿Pensamientos?

Desde que descubrí AssertionHelper hace unos 6 u 8 meses, en realidad he estado migrando pruebas hacia esa sintaxis, cada vez que me encuentro con pruebas que utilizan la sintaxis Assert estática, por lo que en realidad estoy bastante comprometido en mantener esto vivo, si es posible.

@fluffynuts Es genial si quieres convertirte en el mantenedor de AssertionHelper y estaré encantado de ayudarte a hacerlo. Es un poco más difícil hacer que usted sea __parte__ de mantenerlo si NUnit Core Team lo está quitando de NUnit.

@ChrisMaddock @ jnm2 Creo que tus 👍 son un poco ambiguas. ¿Están todos a favor de eliminar AssertionHelper (que creo que ambos votaron) y que alguien más se haga cargo? ¿O estás a favor de la solicitud de

@CharliePoole bueno, si el equipo principal de NUnit está decidido a eliminarlo, ¿quizás la solución más fácil es que me bifurque? Y en algún momento podría implementar el Expect estático que habilitaría using static y significaría que los accesorios ya no tendrían que heredar de AssertionHelper.

Si tuviera que hacer esto, me interesaría algún tipo de notificación del equipo central de NUnit de una próxima versión, de modo que podría intentar lanzar un paquete de nuget con la misma versión según la nueva versión lo antes posible después el lanzamiento de NUnit. Sin embargo, estaría feliz de hacer el trabajo involucrado, siempre y cuando todos en el NUnit Core Team estén de acuerdo con eso. Obviamente, entonces estaría respondiendo cualquier solicitud contra la sintaxis de Expect, pero también tendría la gran ventaja de comenzar con una base de código rica y funcional, sin intentar hacer un Expect-a-like.

¿Pensamientos?

Démosle a los de pulgares arriba la oportunidad de responder. He indicado la dirección en la que __pensé__ que habíamos decidido ir, pero siempre es posible, especialmente si se trabaja de forma remota, tener entendimientos completamente opuestos de la misma discusión.

Con respecto a using static no tengo claro cómo le daría alguna de las ventajas de AssertionHelper __except__ para el verbo Expect . ¿Cómo lidiaría con las limitaciones?

Para ser honesto, no he pensado mucho en la idea más allá de "sería
genial si pudiera obtener la sintaxis Expect sin herencia ".
mirar más de cerca mañana (:

El 31 de mayo de 2017 a las 21:34, "CharliePoole" [email protected] escribió:

Démosle a los de pulgares arriba la oportunidad de responder. He dicho el
dirección que pensé que habíamos decidido ir, pero siempre es posible

• especialmente trabajando de forma remota, para tener entendimientos completamente opuestos
  fuera de la misma discusión.

Con respecto al uso de estática, no tengo claro cómo le daría alguno de los
ventajas de AssertionHelper excepto por el verbo Expect. Como lo harias
lidiar con las limitaciones?

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

Lo que quería ver era el AssertionHelper separado del marco: tenemos mucho que mantener aquí y una gran API y, en mi opinión, es el miembro correcto para cortar. Si hay interés (que parece ser de al menos un usuario), un paquete NuGet separado que depende del paquete marco me parece una solución ideal.

Según entendí, una de las motivaciones para desaprobar, en lugar de la eliminación directa, que también discutimos, fue tener una idea adecuada del uso, y @fluffynuts ha presentado exactamente el tipo de propuesta de la que hablamos, para mantener AssertionHelper como un elemento separado. paquete. ¡De ahí mi 👍!

Me alegraría que se quedara en la organización NUnit, separada del marco. Esto dependería de que cualquier futuro mantenedor esté dispuesto, por supuesto, ¡no me voy a ofrecer voluntario para cuidarlo! Si, por alguna razón, el mantenimiento se interrumpe, podría ver que funciona de la misma manera que las compilaciones SL y CF: sin mantenimiento, pero archivado y listo para cualquiera que desee continuar.

@ChrisMaddock Gracias por aclarar. Todo lo que recordaba era que lo había convertido en un proyecto separado, pero retiré ese cambio porque alguien (tal vez no tú) quería que lo mantuviéramos o lo elimináramos por completo.

Mis pensamientos son los mismos que los de @ChrisMaddock .
También cambia el panorama si no conocemos a nadie que esté motivado para invertir en él, y entonces aparece alguien. Incluso si creo que no deberíamos dedicar más tiempo a eso, nunca voy a votar para impedir que un partido motivado trabaje en algo como esto.

También estoy de acuerdo con que alguien más se haga cargo y lo convierta en un paquete separado que dependa del marco principal. También me complace dividirlo en su propio repositorio en la organización principal si @fluffynuts quiere mantenerlo y publicarlo. Como mínimo, si se trata de un paquete NuGet separado, podemos realizar un seguimiento de las descargas y con ese uso.

@ jnm2 Recuerda que esto es de código abierto. Incluso si lo borramos, todavía existe en el repositorio y cualquiera es libre de bifurcarlo y liberarlo por sí mismo. Realmente no tenemos que decidir si el software funcionará, solo si queremos trabajar en él o asumir la responsabilidad de él.

Dicho esto, creo que es más limpio si lo hacemos en su propio proyecto primero. Entonces, alguien puede bifurcarlo como quiera O puede mantenerlo como parte de nuestro conjunto de proyectos. Lo separé por completo, pero en la revisión del código se decidió no hacerlo, así que retiré el cambio. Sin embargo, es bastante fácil volver a hacerlo si queremos.

Creo que es mejor si tomamos medidas que no tendremos que revertir más tarde. Entonces, por ejemplo, si lo hacemos un ensamblaje separado, luego un paquete separado y luego dejamos de mantenerlo, es una especie de orden natural. Si saltamos demasiado rápido y luego tenemos que retroceder, es una pérdida de esfuerzo.

Entonces, ¿qué estamos haciendo con esto?

@CharliePoole Estoy de acuerdo con lo que "sienta mejor" con el equipo central de NUnit (:

Parece que hay una tendencia general a dividirse en un proyecto separado con su propio paquete: genial.

Lo que me gustaría lograr, si es posible, es que ese proyecto libere paquetes en el paso de bloqueo con el proyecto principal de NUnit (como se mencionó anteriormente: {nuevo proyecto} xyz debería depender específicamente de NUnit xyz - para evitar confusiones sobre qué paquetes jugar bien juntos y también para que una persona perezosa como yo pueda install-package {new project} y traer NUnit con eso.
Creo que sería una victoria si esto se mantuviera como un NUnit "oficial". Sin embargo, no estoy seguro de cómo les gustaría proceder en ese frente. También estoy dispuesto a simplemente bifurcar y sacar AssertionHelper y lanzarlo por mi cuenta, pero esa no es mi preferencia, para ser honesto.
Además, si se generó un nuevo proyecto (ya sea por NUnit Core o yo mismo), me gustaría que el nombre al menos sea aceptable para NUnit Core; no quiero bifurcarlo y llamarlo algo fácil y obvio como " NUnit.

Básicamente, estoy feliz con lo que sea que elijan hacer y todavía estoy dispuesto a mantener cualquier animal que surja.

Creo que sería una victoria si esto se mantuviera como un NUnit "oficial". Sin embargo, no estoy seguro de cómo les gustaría proceder en ese frente. También estoy dispuesto a simplemente bifurcar y sacar AssertionHelper y lanzarlo por mi cuenta, pero esa no es mi preferencia, para ser honesto.

@CharliePoole Por cierto, esto es lo que quise decir con no bloquear. Me gustaría que esto sucediera de forma gratuita ya que @fluffynuts está motivado para invertir en él.

Me complace mantenerlo como un proyecto oficial de NUnit que se mantendrá y publicará mientras la comunidad continúe usándolo y manteniéndolo. También parece que tenemos un acuerdo general de @ nunit / core-team. @CharliePoole , ¿desea restablecer el repositorio anterior que creó para esto o prefiere que lo haga otra persona?

@ jnm2 Para ser claros, en caso de que no fuera antes, estoy a favor de esta idea. Estoy planteando preguntas que tienen que ver con el funcionamiento general del proyecto.

Varias personas en la discusión son miembros del Equipo Central, que tomará decisiones importantes para el proyecto en el futuro. Solo ha sido cuestión de meses desde que decidieron __no__ aceptar mi propuesta de separar AssertionHelper en su propio repositorio.

Aparte de la molestia personal que siento por haber descartado ese trabajo, no creo que el Core Team funcione bien si sus políticas básicas cambian todos los meses.

El hecho de que alguien diga que le gusta Assertion helper no es nuevo. Siempre supimos que tenía seguidores.

El hecho de que alguien se haya ofrecido como voluntario para trabajar en él es nuevo pero, en mi opinión, no debería impulsar la política. Un tablero como el Core Team no debería ser reactivo sino activo. Si fue una buena idea, deberíamos haber estado trabajando para implementarla. Eso incluye buscar activamente un mantenedor.

Me doy cuenta de que este negocio de gobernanza es algo nuevo, por lo que los fallos son inevitables. Pero no detecté ninguna conciencia de que esto fuera una reversión completa de hace poco tiempo.

Y, por supuesto, @ jnm2 acaba de unirse al Core Team.

@fluffynuts Lo siento también haz de tu propuesta un ejemplo. Estoy a favor de un repositorio separado y, como probablemente haya descubierto, ya hice el trabajo para crear uno hace un tiempo.

Pensé que nuestro plan original era no movernos en 3.7 porque era un cambio importante para los usuarios y queríamos darles tiempo para actualizar y permitirnos medir la reacción. Pensé que eliminarlo sin antes desaprobarlo para una versión o dos no era una buena idea.

Pensé que luego decidiríamos si queríamos trasladarlo a un nuevo proyecto y buscar un responsable de mantenimiento o eliminarlo por completo. Tenemos a alguien que quiere mantenerlo, así que estoy de acuerdo con permitir que @fluffynuts lo

Este también fue mi entendimiento.

@rprouse @ChrisMaddock No quiero vencer a un caballo muerto aquí, pero si eso fue lo que entendió, entonces no deberíamos haber fusionado un cambio que marcó AssertionHelper obsoleto, con la notación de que se eliminaría en una versión futura . Envié eso basándome en mi comprensión de lo que estaban diciendo. Si continuamos con el repositorio separado, entonces deberíamos eliminar el ObsoleteAttribute.

¿Tenemos alguna diferencia de opinión sobre lo que significa obsoleto? Pregunta seria. Para mí, significa que la función __definitivamente__ desaparecerá. Creo que así lo toman los usuarios también. No lo usaría para significar que desearíamos que desapareciera o podría desaparecer.

@rprouse ¿Reinstalar? AFAIK, no queda nada por restablecer. Buscaré en GitHub, pero creo que todo eso se eliminó. Localmente, eliminé el código porque no iba a ser necesario; estábamos eliminando la función. Este fue un cambio que realmente quería ver, pero fui rechazado, casi por unanimidad. Me disculpo por mi rencor al respecto, que en realidad no sabía que estaba allí hasta ahora.

Si puedo encontrar restos del cambio, los volveré a colocar en un PR. Si no, prefiero trabajar con @fluffynuts para ayudarlo a configurarlo con una compilación estándar, etc.

Voy a reservar cualquier discusión de "política" adicional para el correo electrónico o el repositorio de gobierno.

Si AssertionHelper se está moviendo a un nuevo paquete NuGet y un nuevo ensamblado, en realidad es bueno que lo hayamos dejado obsoleto del ensamblado del marco NUnit. Solo necesitamos actualizar el mensaje de obsolescencia que ahora le dice a la gente dónde ir para el ensamblaje correcto.

@ jnm2 Obsolete es para cosas que van a desaparecer por completo. Si la nueva clase, donde sea que esté, va a tener el mismo nombre, entonces no deberíamos usar Obsolete. El lugar donde se encuentra la clase es motivo de alguna otra advertencia, probablemente en el comunicado donde ocurre el cambio.

Por otro lado, @fluffynuts ha sugerido algunos nombres nuevos para reemplazar AssertionHelper y estoy de acuerdo en que un nuevo nombre es una buena idea. En ese caso, "AssertionHelper" __ está__ desapareciendo y Obsolete es sensato. El mensaje podría decir "Use SomeOtherClass, que se encuentra en some.other.assembly"

Por supuesto, esto solo importa si publicamos una revisión. Si esperamos 3.8, es posible que ya se haya ido.

He obsoleto las cosas que se mueven entre ensamblajes porque ahora tiene acceso a dos API idénticas disponibles para IntelliSense al mismo tiempo y el mensaje de obsolescencia sería útil, diciendo que no use AssertionHelpers, NUnit.Framework , en su lugar use AssertionHelpers, NUnit.Expectations . Desde el punto de vista de la compatibilidad de API, cambiar el ensamblaje es exactamente el mismo proceso de interrupción y obsolescencia que cambiar el nombre. Por supuesto, somos libres de interpretar las cosas como queramos. No tenemos que seguir eso. Solo estaba reconociendo eso como algo bueno que he visto antes.

@ jnm2 Eso solo es posible si los dos existen al mismo tiempo. Estaba pensando que no lo harían. Supongo que podríamos dejar un AssertionHelper ficticio en el marco y marcarlo como obsoleto. ¿Es eso lo que estás pensando?

En cualquier caso, no podemos hacer eso en este momento, porque la versión separada de AssertionHelper aún no existe. Ahora mismo (3.7.1) es de lo que estaba hablando. ¿Qué usaría durante el período en el que el nuevo asistente de aserción (o el nombre que sea) aún no existe?

@fluffynuts SI vas a hacer esto, te sugiero que propongas un plan para la secuencia de cosas. Nuestro lanzamiento 3.8 probablemente no será hasta dentro de otros 3 meses. Es posible que tengamos uno o más lanzamientos de revisiones: Rob ha programado la 3.7.1 para unos días a partir de ahora.

Incluso sin mejoras y trabajando rápidamente, no puedo imaginar que esté a punto de crear una versión del nuevo asistente de afirmaciones antes de unas pocas semanas a partir de ahora, tal vez un mes.

¿Puede proponer una secuencia de pasos?

¿Qué usaría durante el período en el que el nuevo asistente de aserción (o el nombre que sea) aún no existe?

¿Qué tal si mantenemos el mensaje de que AssertionHelpers se está alejando de NUnit.Framework, lo cual es cierto, o vamos más allá y decimos que tenemos planes tentativos (o firmes) para que se traslade a NUnit.Expectations?

@CharliePoole bueno, una forma de hacer las cosas (no necesariamente de la manera _right_, pero una forma (:)) sería bifurcar el repositorio de NUnit, bajo la cuenta de NUnit, otorgarme acceso de mantenedor / desarrollador y clono, extrayendo sin sentido todo lo que no es AssertionHelper o algo que lo admita directamente, lo que hace que el proyecto de alojamiento de AssertionHelper dependa de un paquete nuget NUnit.
La parte más complicada viene con asegurarme de que lo que he hecho sea aceptable para el equipo de NUnit y luego usar su proceso de compilación y lanzamiento. Si tuviera que piratearlo rápidamente y liberarlo en mi cuenta nuget, no tomaría mucho tiempo, pero no creo que ese sea el camino correcto, personalmente. Me gustaría que el control de este nuevo repositorio y los paquetes producidos a partir de él existieran fuera de mí. No me importa tener el control conjunto, pero ciertamente no quiero que aparezca en Nuget como uno de mis _ paquetes, por lo que si no puedo mantenerlo más, no puedo simplemente entregarlo. para alguien más. El mismo razonamiento se aplica al repositorio.
Entonces, una posible secuencia de eventos podría ser:

1. Bifurcar NUnit bajo la cuenta NUnit
2. Concederme acceso de desarrollador / mantenedor
3. Hackeo y barra para llevar el código fuente a un lugar donde en realidad es solo un AssertionHelper sin modificar con solo lo que necesita para sobrevivir, dependiendo de un paquete NUnit nuget
4. Mientras tanto, el mensaje Obsolete se actualiza para hacer referencia a la instalación de un paquete diferente para obtener la funcionalidad requerida. Este mensaje debe incluir el nombre del paquete final; estoy contento con NUnit.
5. Con suerte, puedo obtener un lanzamiento pronto y solo hay un pequeño contratiempo para los usuarios finales. Si hay "unos pocos días", debería poder completar el lado del código, asumiendo una bifurcación a la velocidad del rayo a su lado. Entonces depende de la revisión del código y asegurar que mi compilación y lanzamiento se alineen con la suya.

Estoy de acuerdo en que Obsolete debería ser para características que definitivamente van a morir, pero este es (imo) un uso aceptable del atributo, aunque sólo sea por el hecho de que no existe algún atributo existente que ofrezca la misma funcionalidad: un advertencia del compilador con instrucciones sobre cómo solucionarlo.

¿Pensamientos?

@fluffynuts Localicé una copia de seguridad local del repositorio nunit-assertion-helper. Puedo cambiarle el nombre a nunit-investments antes de subirlo si a todos les gusta ese nombre. Tengo que mirar el código para ver qué hay, pero parece que tiene una compilación adecuada, etc. Esto es pura casualidad debido a que todavía no lo he purgado de una de mis máquinas.

@ nunit / framework-team @ nunit / core-team
A menos que escuche lo contrario, haré el repo nunit-Expectativas y el ensamblado nunit.expectations.dll. Subiré lo que tengo que dominar del nuevo repositorio; no ha cambiado desde el marco AFAIK. Se pueden abordar más cambios en la revisión del código.

@fluffynuts
Realmente no hay un montón de piratería y corte que hacer para eliminar AssertionHelper. PR # 1250 lo aisló completamente en un solo archivo, con pruebas en otro archivo. No se menciona en ninguna otra parte de NUnit. El nuevo repositorio es lo que decidimos no hacer hace unos meses, pero conservé todos los cambios que aislaron la función.

Tenemos dos posibilidades aquí:

1. La versión de revisión 3.7.1 saldrá antes de que esté lista.
2. Estará lista para publicarse al mismo tiempo que la revisión.

No creo que debamos eliminar AssertionHelper en la revisión en ningún caso. Para eso no es una revisión. Pero probablemente deberíamos cambiar el mensaje en ObsoleteAttribute y será diferente dependiendo de si la situación es 1 o 2. Creo que podemos asumir 2 si quieres hacer un lanzamiento con solo los cambios de nombre. Si desea agregar algunas funciones, entonces es 1. Sin embargo, tenga en cuenta que puede hacer lanzamientos con la frecuencia que desee. El único problema es que será más fácil para todos en este caso si los números de lanzamiento coinciden con los del marco al que hace referencia.

¡Victoria épica de

Creo que la primera versión del paquete debería ser, literalmente, escindirlo de NUnit, es decir, no cambiar nada más que el nombre del ensamblaje y dónde vive el código (:

Preferiría, como se mencionó anteriormente, hacer lanzamientos de paquetes en el paso de bloqueo con NUnit principal, números de versión coincidentes; será más fácil para los usuarios posteriores. Es por esta razón que vuelvo a publicar todos mis propios paquetes PeanutButter. * Cada vez que actualizo alguno de ellos: hace mucho tiempo que algunos usuarios me preguntan qué versiones funcionarán entre sí y es mucho más sencillo hacer coincidir los números de versión.

Para las versiones provisionales de funciones, se podría usar -rc [X] en la versión (básicamente usando el mecanismo de prelanzamiento ; en particular, si estoy trabajando en algo nuevo, me gustaría instalar la tecnología de punta en mi Proyectos propios: nada prueba una idea mejor que comer tu propia comida para perros.

Suena bien para mí.

A menos que los nombres de espacios de nombres / clases cambien, no sería posible usar el nuevo paquete AssertionHelper, mientras que el antiguo AssertionHelper todavía existe en el marco, ¿no es así?

Eso me sugiere que 3.7.1 solo cambia el mensaje obsoleto para mencionar el nuevo paquete, y 3.8 elimina el antiguo asistente de aserción, y es la primera versión del nuevo paquete.

@CharliePoole - Me pregunto si nuestras diferentes ideas de 'obsoleto' es de donde surgió la confusión. De cualquier manera, me alegro de que hayas logrado recuperar el trabajo.

En el nuevo repositorio, lo puse en el espacio de nombres NUnit.Framework.Extensions. Si todo el mundo está de acuerdo, cualquier usuario puede cambiar a la nueva versión en cualquier momento mediante el uso de un alias.

Creé el repositorio y estoy trabajando para cambiar los nombres de ensamblajes y proyectos. Agregará la referencia del paquete a 3.7 y luego solicitará una revisión. @fluffynuts puede continuar desde allí.

@CharliePoole ¿Quién es el cesionario actual de este problema?

Nadie. Estaba tomando la táctica de que los problemas son locales para los repositorios, y este sobre la eliminación del asistente de aserción es un problema de marco. Creé el nuevo repositorio, nunit-generations. Si es necesario, puedo trabajar un poco más y podemos presentar algunos problemas allí.

El lado práctico de esto es que realmente no puede hacer una prueba de integración con el nuevo componente hasta que se cambie el marco y no puede cambiar el marco hasta que el nuevo componente esté listo. 😄

Mi recomendación fue que esto estuviera en la versión 3.8.

Debo agregar ... Supongo que este será un proyecto contribuido, lo que normalmente significa que alguien entra como líder del proyecto en lugar de uno de nuestros confirmadores. Sin embargo, si uno de los miembros más nuevos de nuestro equipo (que yo o Rob) quisiera tomar esto como una primera oportunidad para ser líder de un proyecto, creo que sería una buena experiencia, que tal vez conduzca a cosas más importantes. 😺 🥇 😈

@CharliePoole Me pregunto qué trabajo restante impide que se cierre este problema y si sabemos quién lo hará.

@ jnm2 Este problema trata de eliminar los archivos del marco y documentar cómo las personas deben lidiar con el cambio. Es trivial pero alguien tiene que decidir cuándo hacerlo. Probablemente no queremos que esté disponible, ya que requiere coordinación con el otro proyecto que reemplaza la función.

Probablemente debería obtener la construcción del otro proyecto para que alguien pueda hacerse cargo junto con este problema.

@rprouse ¿Le gustaría que esto se hiciera justo antes del lanzamiento de 3.8 o está bien en cualquier momento durante el período?

Vaya, 60 comentarios. Creo que pasamos más tiempo hablando de cosas que codificando 😈

Si @fluffynuts quiere hacerse cargo del mantenimiento, entonces, ¿qué tal si le damos la oportunidad de bifurcar y preparar una solicitud de extracción? Crearé un repositorio para que él trabaje y podremos ver cómo va, solo di la palabra.

En cuanto a eliminar AssertionHelper de este proyecto, simplemente lo desaprobamos en 3.7. ¿Qué tal si esperamos un lanzamiento para que las personas tengan tiempo de actualizar su código? También le dará a @fluffynuts la oportunidad de sacar algo. Si se mueve rápido, siempre podemos volver a evaluar para la versión 3.8, ya que los usuarios tendrán algo a lo que cambiar.

@rprouse Estoy de acuerdo con hablar.

Quizás hay tantos comentarios que se está perdiendo la esencia. ¿Por qué necesitamos un tenedor? Ya hicimos todo el trabajo y lo fusionamos ... sin soltar dos archivos. El repositorio separado ya existe.

Creo que en realidad espera a que digas __cuando__ quieras que suceda, apenas queda trabajo por hacer y el riesgo es que se haga demasiado pronto y luego se estanque si no estás listo para fusionarlo.

Asumí que querrías que desapareciera en 3.8 y te preguntaba si querías esperar para hacerlo en la rama de lanzamiento o si querías que se hiciera ahora, por lo que desaparecería para cualquiera que use compilaciones de desarrollo.

@CharliePoole Claramente me perdí algo mientras me @fluffynuts a crear una versión, creo que podemos continuar con la eliminación de AssertionHelper de este repositorio y hacer la versión separada de AssertionHelper justo antes de la 3.8.

Si no tenemos una versión separada de AssertionHelper disponible, preferiría esperar otra versión para que la gente tenga más tiempo para actualizar.

Simplemente no creo que debamos hacer el trabajo de mantener AssertionHelper. Si la comunidad lo quiere y da un paso adelante, entonces nos permite eliminarlo del marco antes porque habrá una alternativa fácil. Si la comunidad no da un paso al frente, le damos a la gente un poco de tiempo y desaparece en 3.9.

Ver https://github.com/nunit/nunit/issues/1212#issuecomment -311964899

Resumen: encontré una copia de seguridad del repositorio local que creé y la cargué en https://github.com/nunit/nunit-expectations. Fusionamos PR # 1250 en febrero, lo que eliminó todo nuestro uso de AssertionHelper y lo aisló en dos archivos.

Creo que debería echar un vistazo para refrescar mi memoria y crear según sea necesario en las expectativas de nunit ... es decir, ¿se construye, etc.?

Hola a todos

Esto ha estado abierto por un tiempo. Sé que me ofrecí para mantener AssertionHelper, pero es posible que haya encontrado una manera que haga felices a todos: las personas que quieren sacarlo, así como las personas (como yo) que actualmente usan la sintaxis.

Puse para revisar mi código rápido de anoche: https://github.com/fluffynuts/NUnit.StaticExpect que está en nuget.org . He usado esto para reemplazar todos los usos de AssertionHelper en un proyecto, aunque es posible que mi uso no sea tan extenso como el de otros, por lo que agradezco los comentarios.

Básicamente, es solo una envoltura alrededor de las llamadas Assert.That , pero proporcionó un reemplazo directo para AssertionHelper, al menos, para mí. Y logra mi objetivo de no requerir que todos los dispositivos de prueba hereden de otra clase.

También me proporciona una solución temporal cuando termino una primera versión de Expect(value).To.Equal(otherValue) ) con una experiencia similar a Jasmine para la extensión del consumidor. Se acopla con NUnit, sin depender directamente de él, arrojando AssertionExceptions si el tipo se encuentra en tiempo de ejecución, de lo contrario arroja sus propias excepciones.

Hasta ahora, está tomando forma, pero quiero incluir algunas características más antes de la versión 1.0. Si algún usuario de Expect está interesado, tal vez vea este proyecto o hágamelo saber para que pueda mantenerlo actualizado.

@fluffynuts Parece una buena alternativa. ¿Sabe si otros IDE y compiladores admiten la sintaxis?

En cuanto a nuestro propio soporte de NUnit, lo que veo que está sucediendo es que me aseguraré de que el nuevo proyecto se esté construyendo después de mis vacaciones, y luego dejaré el cronograma de cambio en manos de

@CharliePoole using static es parte de la especificación C # 6 https://msdn.microsoft.com/en-us/magazine/dn802602.aspx por lo que _debe_ ser compatible con cualquier cosa que admita la sintaxis C # 6 (:

Si bien puede haber compiladores que no conozco que no admitan esto, ciertamente cualquier Visual Studio moderno lo admitirá de inmediato. Las versiones anteriores de Visual Studio (y supongo que otros procesos que usan msbuild) pueden obtener soporte a través del paquete Microsoft.Net.Compilers nuget (y luego también obtienen soporte C # 7, lo cual también es bueno (:)).
Mono admite C # 6: http://www.mono-project.com/docs/about-mono/languages/csharp/ y estoy asumiendo audazmente que dotnet core, siendo el nuevo chico en el bloque, admite un especificación de 2014 (:

Entonces, aunque creo que esta debería ser una alternativa viable para todos, también estoy bastante abierto a que me digan que estoy equivocado (:

Por lo tanto, al menos es posible que el equipo del marco elimine esta función por completo, siempre que no les importe la pérdida de compatibilidad con versiones anteriores para lo que probablemente sea un pequeño número de usuarios.

Personalmente, seguiría manteniendo el proyecto por separado, pero no lo mejoraría en el futuro.

Estoy de acuerdo, aunque no me impacta, NUnit tiene un alcance muy amplio y estoy seguro de que hay alguien a quien impactaría.

Después de discutir con @BobSammers , quien ha hecho una valiosa contribución a NUnit.StaticExpect, me gustaría recordarle a cualquiera que esté suscrito o que se encuentre con este hilo que NUnit.StaticExpect (nuget: https://nuget.org/packages/NUnit .StaticExpect ) proporciona un reemplazo

No quería ser un troll en este foro, pero @BobSammers señaló que tal vez la gente no se dio cuenta de la integridad de la solución y de lo fácil que es cambiar, así que lo estoy

Es bueno ver que NUnit.StaticEspere recibir atención @fluffynuts : ¡esta es una gran solución al problema!

@ nunit / framework-team: creo que probablemente estemos cerca de poder resolver este problema. ¿Puedo proponer lo siguiente, en función de dónde nos encontremos ahora?

1. AssertionHelper permanece obsoleto y sin mantenimiento durante el resto de la serie 3.x.
2. AssertionHelper se elimina en 4.0
3. Actualizamos la documentación y ObsoleteAttribute para recomendar NUnit.StaticExpect como reemplazo directo.
   ~ 4. NUnit.StaticExpect sigue vivo como una biblioteca de terceros, que ahora proporciona una sintaxis _alterna_, a diferencia de una sintaxis "heredada". Anteriormente hablamos sobre hacer esto dentro de la organización NUnit; ya no veo ninguna razón para traer esto a la organización. @fluffynuts : si no está de acuerdo en absoluto, personalmente no tendría ninguna objeción a trasladar esto a la organización, pero creo que la clave es que su mantenedor siga siendo un proyecto independiente. 🙂 ~ ( Se discutirá en gobernanza )

Todos los pensamientos son bienvenidos: @rprouse probablemente debería hacer la última llamada aquí, dadas las implicaciones.

@ChrisMaddock No tengo ningún problema en llevar esto a la organización NUnit en absoluto; de hecho, creo que podría ser una buena idea porque parecerá una alternativa más "oficial" en lugar de un código creado por un código arbitrario. code-monkey en las interwebs (: No estoy seguro de cómo se logra esto, así que agradezco la información (:

También tengo la intención de seguir siendo mantenedor, pero podría ser una buena idea, si hay suficiente interés en el proyecto, proporcionar acceso completo a otra persona (tal vez @BobSammers , que ya ha contribuido), para los típicos "atropellados por un autobús "momentos.

Se debe hacer lo mismo para la administración de paquetes en nuget.org, por las mismas razones.

@fluffynuts ¡

Discutamos el futuro de NUnit.StaticExpect por separado, en la gobernanza , y conservemos este problema para decidir qué hacer con el NUnit.Framework.AssertionHelper actual, para que podamos eliminarlo. No tengo tiempo por ahora, pero escribiré un problema esta noche para comenzar la discusión.

Siguiendo con el tema de este problema, ¿cómo afecta la existencia de NUnit.StaticExpect nuestra decisión sobre AssertionHelper ? No había oído hablar de él antes y parece una excelente solución. Estaba listo para dejar caer AssertionHelper frío, incluso sin un reemplazo, y todavía lo estoy. ¿Qué pasa con otros miembros de @ nunit / framework-team? ¿ NUnit.StaticExpect como alternativa lo lleva a estar listo para dejarlo?

Como un asunto menor, no llamaría a esto un reemplazo "directo" ya que el usuario tiene que cambiar el código. Es un pequeño cambio, pero sigue siendo un cambio. Sospecho que también podría ser un reemplazo para los usuarios de C #. En cualquier caso, espero que sea un reemplazo suficiente para hacer que aceleremos la caída de AssertionHelper .

¿NUnit.StaticExpect como alternativa lo lleva a estar listo para dejarlo?

Si nuestras notas de la versión, y lo que la gente verá de forma visible en el administrador de paquetes NuGet, muestra una advertencia en la parte superior de la descripción como, "Advertencia: el AssertionHelper obsoleto se ha eliminado. Para continuar usándolo, también debe hacer referencia a NUnit. Paquete StaticExpect ". - luego, personalmente, estoy igualmente feliz de hacerlo en el próximo lanzamiento menor o de seguir esperando.

@ jnm2 El aviso debería ser más como "hacer referencia al paquete NUnit.StaticExpect" y

• dejar de heredar de AssertionHelper
• agregar una declaración de uso
• posiblemente algunas correcciones de código ( @fluffynuts, ¿hay algo más?)

Todavía lo dejaría yo mismo. El uso de métodos estáticos de IMO StaticExpect en lugar de la herencia es una mejora significativa.

@CharliePoole No puedo pensar en nada para agregar, de repente, aunque la mayor parte de lo que mencionas ya debería estar en el README.md (y si hay algo que no lo esté, debería agregarse; de ​​hecho, este README debería , imo , proporcione toda la información que una persona necesita para cambiar, ¡porque sería tonto y molesto si no lo hiciera!).

Entonces, si tiene tiempo, agradecería una revisión y un comentario en https://github.com/fluffynuts/NUnit.StaticExpect/blob/master/README.md de manera que incorpore, de una manera fácil de seguir , los pasos necesarios para pasar de AssertionHelper a NUnit.StaticExpect. Si ese README.md se vuelve lo suficientemente claro y definitivo, podría ser lo suficientemente bueno como para hacer que el aviso de obsolescencia sea algo como "AssertionHelper ha quedado obsoleto en favor de NUnit.StaticExpect. Lea https://github.com/fluffynuts/NUnit.StaticExpect/ blob / master / README.md para obtener más información ".
¿Pensamientos?

@fluffynuts Lo único que me gustaría ver agregado serían algunos ejemplos más, por ejemplo:

• Uso de restricciones (reemplazando la sintaxis Is y Has )
• Usar con otros que no sean Afirmar / Esperar: por ejemplo, asumir, advertir.

Solo quería asegurarme de que sea un reemplazo completo (o avisar si no lo es)

¿Cuál es el problema con el código que no es de C #? ¿Puedes usarlo en VB por ejemplo?

@fluffynuts Para ser claros, me AssertionHelper sin un reemplazo, pero he estado en minoría. Sin embargo, si recomendamos un reemplazo, me gustaría dejar completamente claro qué reemplaza y qué no reemplaza (si es que hay algo). Me gusta la idea de que su archivo Léame lo explique todo.

@CharliePoole Estoy totalmente de acuerdo con la idea de que un archivo Léame al que se dirige el usuario debe ser explicativo y claro. También soy consciente de que puedo perderme algo que usted (o cualquier otra persona del equipo de NUnit) pueda considerar importante, de ahí la llamada a revisión. Con ese fin, y para responder a algunas de las cuestiones que plantea:

• Ciertamente agregaré algunos ejemplos más.
• Suponga que / Warn parece no ser parte de la sintaxis AssertionHelper , por lo que actualmente no están implementados en NUnit.StaticExpect . Actualmente, tenemos dos métodos de prueba para probar la paridad: pruebas basadas en la reflexión que muestran que (en todos los casos menos en 2) que los métodos y propiedades que se encontrarían en AssertionHelper se imitan a través de métodos y propiedades estáticos en Expectations (los dos mencionaron tener pruebas de comportamiento de casos especiales ya que se han desviado de la firma exacta ofrecida por Assert.That ) así como el accesorio de prueba completo AssertionHelper ejecuta contra Expecations lugar de heredar de AssertionHelper . El objetivo principal del proyecto es proporcionar un reemplazo de dolor mínimo por AssertionHelper , por lo que ese es prácticamente el estado actual. Por supuesto, Assume y Warn todavía están disponibles para el usuario a través de llamadas regulares.
• código no C #: esta es una buena pregunta. Todo es .net, así que, claro, puede usarlo desde, digamos, VB; pero creo que su pregunta es más sobre importaciones estáticas en VB.NET, una pregunta que no puedo responder en este momento (y que mi google-fu no ha podido responder hasta ahora), pero para la que encontraré una respuesta definitiva por simplemente creando un proyecto y probándolo. Debería poder informar aquí más tarde sobre esto.

Y para reiterar, para mayor claridad: agradezco la revisión, los comentarios y las sugerencias sobre el README porque realmente debería ser un punto de aterrizaje amigable e informativo para cualquiera que esté considerando el cambio a NUnit.StaticExpect . Todas las sugerencias son bienvenidas.

@CharliePoole para mi alegría:
Imports NUnit.StaticExpect.Expectations
proporciona la misma funcionalidad en VB.NET que
using static NUnit.StaticExpectations.Expectations
hace en C #. Acabo de probar esto ahora en una pequeña biblioteca de prueba de VB.NET.

(y, como nota al margen, ahora entiendo por qué AssertionHelper copió los métodos en (por ejemplo), Is - porque no puedo, en VB.Net, hacer
Expect(1, Is.EqualTo(1)) ,
pero puedo (a través de la importación estática) hacer:
Expect(1, EqualTo(1))

Así que solo necesito desarrollar más el archivo README. Puedo echarle un vistazo esta noche (:

Solo estaba pensando que quizás desee que las personas sepan que pueden usar Assume o Warn junto con las propiedades de construcción de restricciones estáticas.

WRT Is en VB - por eso tenemos Iz . 😄

Como mencionó @fluffynuts , StaticExpect prueba la funcionalidad AH través de la reflexión para garantizar una cobertura completa de AH . Actualmente, 2 de estas pruebas fallan (en realidad, están descartadas) porque la funcionalidad de AH ha divergido de los miembros Is y Does que oculta (específicamente InRange y Exactly , respectivamente).

Me interesaría saber cuánto tiempo es probable que permanezca AH en NUnit. Si es probable que sea para un par de lanzamientos más (lo cual tiene sentido si se pueden incluir señales de StaticExpect en su mensaje de obsolescencia), ¿estaría interesado en recibir una solicitud de extracción para cambios en AssertionHelper.InRange() y AssertionHelper.Exactly() para cerrar la divergencia (supongo que AH se dejó atrás accidentalmente)? Esto daría a AH y SE exactamente equivalentes en funcionalidad antes de que AH quede obsoleto (¡y ayudaría con el conjunto de pruebas SE !).

@BobSammers No hemos estado agregando características a AssertionHelper por un tiempo, así que no me sorprende que se haya quedado atrás en algunas características nuevas. Siéntase libre de crear un problema para cualquier divergencia que desee solucionar ... Lo digo de esa manera, porque probablemente no tendría mucha prioridad de otra manera.

@ nunit / framework-team No ha habido muchos comentarios recientes aquí, por lo que es difícil responder a @fluffynuts y @BobSammers de una manera significativa. Parece que "en cierto modo" decidimos deshacernos de AssertionHelper en el pasado y yo __creo__ que estábamos planeando dirigir a los usuarios al ensamblado separado que creé. Pero parece que sufrimos un poco por la falta de una decisión clara.

Creo que hemos tenido dos direcciones fundamentalmente diferentes bajo discusión hasta ahora:

1. Detenga el soporte para AssertionHelper completo.
2. Muévalo a un paquete separado, que luego podemos desaprobar y eliminar.

Todas las otras opciones que discutimos me parecen solo detalles en un caso u otro. La mayoría de ellos tienen que ver con la rapidez con la que implementamos una estrategia u otra.

La disponibilidad de StaticExpect parece hacer que la alternativa (2) sea un poco tonta. No hay ninguna razón para que compitamos con StaticExpect , especialmente porque parece una mejor solución que la herencia. Supongo que esto podría abrir una tercera opción, si queremos seguir soportando la API

1. Incorpore StaticExpect en NUnit, reemplazando AssertionHelper . De hecho, NUnit tenía una clase estática llamada ConstraintFactory hasta hace muy poco, que podría haberse usado de la misma manera que StaticExpect si alguno de nosotros hubiera pensado en ello. 😞

@rprouse Esto me parece una de esas decisiones estratégicas que el líder del proyecto debe tomar de una forma u otra. Después de eso, podemos debatir los detalles.

Independientemente de cómo vayan las cosas, he actualizado README.md esta noche, en gran parte tomando prestado de la documentación de AssertionHelper.
Como nota al margen, también actualicé la solución para usar un solo proyecto de múltiples objetivos, por lo que es un poco más ordenado. E incluyó documentación XML generada en el paquete.

@ nunit / framework-team No ha habido muchos comentarios recientes aquí, por lo que es difícil responder a @fluffynuts y @BobSammers de una manera significativa.

Lo siento Charlie, ¡pero solo han pasado un poco más de 24 horas! Miedo de que no siempre puedo responder a las cosas tan rápido. 😞

Anteriormente, estaba interesado en eliminar AssertionHelper en una versión menor. Lo que cambió mi opinión fueron los problemas que vimos al eliminar TestFixtureSetUpAttribute, etc.en 3.8. Para resumir, en 3.8 eliminamos algunos atributos que habían quedado en desuso desde 3.0, asumiendo que esto sería una solución trivial de búsqueda / reemplazo para cualquier usuario que aún dependa de ellos. Lo que descubrimos es que ciertas bibliotecas de terceros todavía dependían de estos atributos, lo que significa que los usuarios de estas bibliotecas de terceros no podían actualizar NUnit hasta que se parcheó la biblioteca. Por supuesto, eso no es imposible, pero significó que lo que asumimos que sería una solución trivial, no era en absoluto para varios usuarios. Bien puede aplicarse aquí la misma situación.

AssertionHelper ahora está completamente segregado del resto del código base gracias al trabajo de

Con respecto a los puntos que expuso Charlie, estoy de acuerdo (2) ahora sería una tontería. En (3) - Personalmente estoy interesado en reducir la API central que estamos proporcionando, y creo que NUnit.StaticExpect sería una excelente sintaxis alternativa de terceros, en lugar de algo que debería ser parte de la biblioteca central. Mi preferencia general seguiría siendo la que propuse anteriormente , ¡pero creo que tendremos que aceptar estar en desacuerdo allí!

Esta noche también daré inicio a este tema de contribución al proyecto en la gobernanza; lo siento, ayer se me acabó el tiempo.

Tema separado para discutir la incorporación de NUnit.StaticExpect a la organización NUnit: https://github.com/nunit/governance/issues/33

@ChrisMaddock En realidad, ¡tú eres el que ya respondió! Dicho esto, parece que hemos dejado esto indeciso durante unos nueve meses y hemos estado en silencio desde julio, hasta que @fluffynuts lo presionó de nuevo.

Me gusta tu propuesta con una reserva. Creo que deberíamos modificar el mensaje Obsolete para recomendar el uso de StaticExpect ahora, en lugar de esperar.

FWIW, mi deseo de eliminar esto antes se basaba en la noción de que tenía que estar presente como parte del equipo para poder agregar mi proyecto de reemplazo. Solo quería sacar un proyecto pendiente de mi plato. Si podemos colocar un paquete AssertionHelper por separado como opción, me alegra que la función permanezca hasta la 4.0.

Me gusta tu propuesta con una reserva. Creo que deberíamos modificar el mensaje Obsolete para recomendar el uso de StaticExpect ahora, en lugar de esperar.

Estoy de acuerdo, estos fueron pensados ​​como tres puntos separados, no como una lista ordenada. 😄

Creo que https://github.com/nunit/nunit/issues/1212#issuecomment -337695330 captura con mucha precisión mis pensamientos (y se expresa mucho mejor de lo que puedo hacer), especialmente con respecto a la "reducción de la API central".