Sinon: De lo contrario, versión 2.0

Me gustaría crear un nuevo sitio web de documentación, basado en el trabajo que ya está en /docs . Espero dedicar algunas horas a eso durante mis vacaciones la próxima semana.

@mroderick Si tienes el trabajo empujado a alguna parte, avísame. ¡Podría ayudar con los documentos!

Se actualizaron las casillas de verificación. No estoy seguro de si se debe marcar "Migrar sinon.sandbox", pero al menos el PR está cerrado.

@jonnyreeves : no estoy seguro de por qué deberíamos eliminar sinon.test . Esta es una caja de arena alrededor de la prueba que limpia cualquier código auxiliar creado y lo espía automáticamente después de la prueba. Eso alivia a las personas de muchas funciones beforeEach y afterEach . Muy útil y tiene poco que ver con los marcos de prueba.

Los usuarios necesitarían ver una alternativa fácil a esto para que esto se elimine en favor de otra cosa (mejor).

Nunca he usado sinon.testCase yo mismo, probablemente porque su api se ajusta a BusterJS (donde cada caso de prueba es una propiedad del conjunto de pruebas) y no a Mocha (donde cada prueba es una función anónima que se ejecuta en el cuerpo del conjunto de pruebas) ).

@ fatso83 El principal problema que tengo con sinon.test es el hecho de que se basa en el singleton sinon.config . En mi humilde opinión, los usuarios pueden tener mucho más control al crear (y restaurar) una caja de arena en los ganchos beofreEach y afterEach su marco de prueba.

Si vamos a mantener sinon.test (y sinon.testCase ) en la API pública; entonces tenemos que abordar ambos problemas, aunque soy un usuario / soporte de sinon desde hace mucho tiempo, soy nuevo en piratear su proyecto, ¿cómo deberíamos llegar a consensous?

@jonnyreeves De acuerdo, tenía más sentido cuando mencionaste que se basaba en sinon.config . En mi humilde opinión, crear y restaurar cajas de arena explícitamente está bien siempre que proporcionemos esto como una alternativa para las personas que vienen de Sinon 1 y se preguntan qué pasó con sinon.test . Entonces, la documentación debería leer algo como

sinon.test

_Esto ha quedado obsoleto en la versión 2 a favor de la creación explícita de una caja de arena. Ver link to sandbox ._

Estoy a favor de una API más sencilla en la versión 2, por lo que cosas como typeOf , extends y sinon.test* podrían ser mejor servidas por otros módulos de NPM u otra funcionalidad existente.

Creo que algo como npm install sinon-test y var sinonTest = require('sinon-test')(config); podría ser un reemplazo decente.

: +1: para mover utilidades como esta en módulos npm separados. Menos código en core

Gracias por el aporte; Actualicé la descripción general en la parte superior para reflejar la discusión hasta ahora (principalmente eliminando los signos de interrogación, aclarando las tareas), por favor, eche un vistazo.

Además, ¿podríamos obtener un cierre similar en:

• eliminando sinon.log y sinon.logError (ambos son utilizados por fake_server; y probablemente sería mejor pasarlos como configuración a esas instancias)
• eliminando sinon.mock de 2.0

Gracias

Nunca usé sinon.testCase , sin embargo, soy un gran usuario de sinon.test . Estoy de acuerdo con que vaya a una biblioteca separada, pero no lo olvides: hay bastantes personas que usan marcos de prueba que no admiten beforeEach por diseño (por ejemplo, cinta) con el argumento de que estas configuraciones Las funciones conducen a casos de prueba acoplados. Podríamos causar muchos problemas a estos usuarios si no hay un reemplazo fácil de instalar.

Supongo que podríamos ofrecer algo como esto como ruta de migración:

sinon.test = require('sinon-test');

@mantoni : Gran sugerencia. Simplemente asignando a la propiedad test que ahora no se usa, le da a las personas la menor cantidad de molestias al incluir una línea adicional en sus pruebas. Solo tenemos que asegurarnos de que el objeto sinon no esté congelado (como en Object.freeze(sinon) ) en algún momento ...

@jonnyreeves : con respecto a sinon.mock , recuerdo que @mroderick sugirió esperar hasta que se lanzara 2.0 antes de eliminar esto. Ya hemos señalado durante algún tiempo que ha quedado obsoleto, por lo que debería estar bien eliminarlo después de la versión 2.0 en mi humilde opinión. Pero como ya tenemos soporte para CommonJS, no me importaría eliminarlo antes de la versión 2.0 _si_ hemos extraído el código en un módulo propio. Entonces la gente podría simplemente let sinon.mock = require('sinon-mock') , si así lo quisieran.

Con respecto a sinon.log* , no veo ninguna razón para aferrarme a ellos como características públicas si pudiéramos proporcionarlos como configuración cuando sea necesario.

WRT factorizando un sinon-test , solo tenga en cuenta que necesitaríamos permitir que los consumidores proporcionen una configuración, es decir:

sinon.test = require('sinon-test').withConfig({ ... });

o similar.

Acabo de detectar otro posible cambio de API al crear un paquete sinon-test ; ¿Alguna idea sobre lo que debería pasar con sinon.assert ? Nuevamente, esto no me parece una parte central de la API de sinon y puede ser más adecuado migrar a un paquete sinon-test junto con sinon.test y sinon.testCase ?

@ fatso83 @mantoni @cjohansen; Tengo una compilación funcional de un paquete sinon-test listo para su revisión. ¿Podría alguno de ustedes inicializar un repositorio de git vacío en sinonjs/sinon-test para que pueda generar un PR en su contra, por favor?

Gracias

¡Eso fue rápido! https://github.com/sinonjs/sinon-test

@cjohansen, ¿ podrías

Hecho

Gracias, relaciones públicas planteadas - comentarios bienvenidos: https://github.com/sinonjs/sinon-test/pull/1

@mroderick Si tienes el trabajo empujado a alguna parte, avísame. ¡Podría ayudar con los documentos!

@spinningarrow eso sería genial. He creado el número 991 para realizar un seguimiento de esto por separado del resto del esfuerzo. Actualizaré esto en los próximos días con mis pensamientos, y podemos continuar desde allí.

De vez en cuando tenemos algunos problemas relacionados con las simulaciones. Ahora que @jonnyreeves ha hecho el arduo trabajo de extraer el módulo, ¿no tendría sentido mover el módulo a un repositorio si es propio? Entonces podríamos mover todas las discusiones relacionadas con las simulaciones allí y cerrar los problemas aquí. Esto es principalmente para aliviar la carga administrativa.

De vez en cuando tenemos algunos problemas relacionados con las simulaciones. Ahora que @jonnyreeves ha hecho el arduo trabajo de extraer el módulo, ¿no tendría sentido mover el módulo a un repositorio si es propio? Entonces podríamos mover todas las discusiones relacionadas con las simulaciones allí y cerrar los problemas aquí. Esto es principalmente para aliviar la carga administrativa.

Eso también significaría la carga administrativa de mantener ese repositorio sincronizado con las herramientas de desarrollo, etc.
¿Quizás deberíamos asegurarnos de que tenemos herramientas de desarrollo compartidas fáciles configuradas primero? cc: @mantoni

@mroderick @ fatso83 De acuerdo, veamos si podemos sacar 2.0 por la puerta.

Actualicé la descripción general de este problema para cubrir lo que considero que son todas las migraciones pendientes (incluida la CJSification del conjunto de pruebas, por favor, si está leyendo esto, ¡ayuda!). Eche un vistazo y avíseme si está de acuerdo con el trabajo sobresaliente.

Además, me gustaría llegar a un consenso sobre lo siguiente:

1. ¿Deberíamos eliminar typeOf y extend de la API pública ( sinon. ), o deberíamos esperar a Sinon 3.x que (supongo) se someterá a una modernización de la API? .
2. ¿Deberíamos eliminar el soporte / hacks heredados de IE de 2.0? Esto _ puede_ simplificar la migración, ya que podríamos eliminar el código 'fakeXDM'; no he mirado de cerca, por lo que todavía no puedo estimar este trabajo.
3. ¿El envío del nuevo sitio de documentos es un requisito previo de la versión 2.0? Me preocupa que no tenga mucha tracción :)

Gracias a todos.

@jonnyreeves : Ciertamente has estado muy ocupada esta noche 😺. Tengo unas largas vacaciones por delante, por lo que ciertamente podría ayudar con las migraciones sobresalientes del conjunto de pruebas (hay un "pero" a continuación).

Respecto a tus puntos:

1. Deberían irse. Pensé que esto estaba bastante resuelto (ref, la descripción general anterior).
2. Primero definamos "IE heredado". ¿Versiones <10, o todo el paquete sinon-ie ? IE9 todavía se estaba enviando con una extraña alternativa CORS llamada XDR. Si hay alguien que todavía pretenda admitir versiones de IE lanzadas antes de 2012, siempre podría usar la rama 1.x, supongo. ¿No estás seguro de a qué te refieres con XDM? No estoy seguro para qué versiones de navegador sinon-ie se necesitan, por lo que no puedo ser demasiado grandilocuente acerca de que el paquete no es necesario. Debemos estar seguros de las consecuencias.
3. La documentación _es_ un punto débil en este momento, pero no estoy seguro de qué decir aquí. Podría comenzar a profundizar en el número 991 antes de ayudar con los otros puntos anteriores. Tener un lugar para enviar documentos mejoraría la vida.

¿Tienes curiosidad por saber cuál es el estado de esto? No parece que haya habido mucho progreso desde hace ~ 6 meses; Actualmente, dependo de un prelanzamiento por varias razones (el soporte de Symbol en funcionamiento es enorme); no me refiero a presionar, pero un simple 'hay unlínea de tiempo '/' todavía no hay una línea de tiempo '¡sería genial! <3

@ELLIOTTCABLE como no tenemos fondos, no hay un

1. Aunque vea "... referenciado el 8 de julio de 2016" arriba, eso solo significa que el primer comentario de la lista es de esa fecha. El último número, # 1235, hizo referencia a esto "hace 12 días".
2. La lista de problemas está casi completa, a diferencia de hace medio año.

Así que ... estamos llegando a algún lado, pero supervisar las correcciones de errores de la versión anterior, así como el suministro constante de nuevas funciones, absorbe gran parte de nuestro tiempo de mantenimiento. Solo investigar y escribir esto tomó media hora al final 😅

Básicamente, después de revisar la lista anterior, solo quedan dos problemas principales:

• "Migrar fake_server y amigos" (90% resuelto, solo queda un poquito - ver arriba).
• Publique el sitio web (vea el n. ° 1220: una tarea menor, súper fácil y una tarea mediana en juego)

Creo que la mayoría de las otras marcas de verificación no cerradas anteriores se relacionan con versiones antiguas de IE (6-10) que estoy bastante seguro de que no serán compatibles, según las discusiones en el n. ° 1221, por lo que pueden ignorarse. Abordaré eso ahora.

@ sinonjs / sinon-core: el comentario anterior me hizo consciente de que tenemos algunos problemas anteriores que no es probable que completemos en función de la discusión en el n. ° 1221:

1. ¿Eliminar el soporte / las soluciones alternativas de Legacy IE?
2. Arreglando xdomain

¿Le importa si creo un PR para eliminar los bits de IE heredados si no los tocamos de todos modos? Supongo que xdomain puede terminar en el vertedero histórico, ya que fue principalmente un truco similar a CORS solo para IE, por lo que se puede eliminar.

@ fatso83 Ahhhh, k. Me perdí los comentarios actualizados sobre los problemas a los que se hace referencia. ¡Espero que revisar esto para mí sea de utilidad para ti!

Sin relación: parece que parte de esto es abandonar el soporte para IE6. Eso es lamentable. ¡Ah, bueno, c'est la marche du progrès! / =

Básicamente estamos ahí, el sitio de documentos tiene su propio problema.

Hola amigos, ¿hay algo que nos impida marcar 2.0 como la versión "estable" de Sinon y matar a 1.x? :)

Creo que queríamos el # 1297 como lo último.

¿ETA en eso? Sugiero que enviemos a más tardar la próxima semana, posponiendo esa característica si no está lista.

Ustedes son hermosos. <3