Sinon: Sinon 2.0 Release

J'aimerais créer un nouveau site Web de documentation, basé sur le travail qui est déjà dans /docs . J'espère y consacrer quelques heures pendant mes vacances la semaine prochaine.

@mroderick Si vous avez poussé le travail quelque part, faites-le moi savoir. Je pourrais peut-être t'aider avec la doc !

Mise à jour des cases à cocher. Je ne sais pas si "Migrer sinon.sandbox" doit être coché, mais au moins le PR est fermé.

@jonnyreeves : sinon.test . Il s'agit d'un bac à sable autour du test qui nettoie tous les stubs créés et espionne automatiquement après le test. Cela soulage les gens de beaucoup de fonctions beforeEach et afterEach . Très utile, et a peu à voir avec les frameworks de test.

Les utilisateurs auraient besoin de voir une alternative facile à cela pour que cela soit supprimé en faveur de quelque chose d'autre (mieux).

Je n'ai jamais utilisé sinon.testCase moi-même, probablement parce que son api correspond à BusterJS (où chaque cas de test est une propriété de la suite de tests) et non à Mocha (où chaque test est une fonction anonyme exécutée dans le corps de la suite de tests ).

@fatso83 Le principal problème que j'ai avec sinon.test est le fait qu'il repose sur le singleton sinon.config . Les utilisateurs IMHO peuvent avoir beaucoup plus de contrôle en créant (et en restaurant) un bac à sable dans les crochets beofreEach et afterEach leur framework de test.

Si nous voulons garder sinon.test (et sinon.testCase ) dans l'API publique ; alors nous devons résoudre ces deux problèmes - bien qu'un utilisateur / support de longue date de sinon, je suis nouveau dans le piratage de son projet - comment devrions-nous parvenir à un consensus?

@jonnyreeves OK, cela avait plus de sens lorsque vous avez mentionné que cela reposait sur sinon.config . À mon humble avis, la création et la restauration explicites de bacs à sable sont acceptables tant que nous fournissons cela comme alternative aux personnes venant de Sinon 1 et se demandant ce qui est arrivé à sinon.test . Donc, la documentation devrait lire quelque chose comme

sinon.test

_Ceci a été déprécié dans la version 2 en faveur de la création explicite d'un sandbox. Voir link to sandbox ._

Je suis tout à fait pour une API plus légère dans la version 2, donc des trucs comme typeOf , extends et sinon.test* pourraient être mieux servis par d'autres modules NPM ou d'autres fonctionnalités existantes.

Je pense que quelque chose comme npm install sinon-test et var sinonTest = require('sinon-test')(config); pourraient être un remplacement décent.

:+1: pour déplacer des utilitaires comme celui-ci dans des modules npm séparés. Moins de code dans le core

Merci pour la contribution ; J'ai mis à jour l'aperçu en haut pour refléter la discussion jusqu'à présent (principalement en supprimant les points d'interrogation, en clarifiant les tâches), veuillez jeter un œil.

De plus, pourrions-nous obtenir une fermeture similaire sur :

• supprimer sinon.log et sinon.logError (les deux sont utilisés par le fake_server ; et il serait probablement préférable de les transmettre en tant que configuration à ces instances)
• suppression de sinon.mock de 2.0

Merci

Je n'ai jamais utilisé sinon.testCase , mais je suis un gros utilisateur de sinon.test . Je suis d'accord pour qu'il entre dans une bibliothèque séparée, mais pour ne pas oublier : il y a pas mal de gens qui utilisent des frameworks de test qui ne prennent pas en charge beforeEach par conception (par exemple une bande) avec l'argument que ces configurations les fonctions conduisent à des cas de test couplés. Nous pourrions causer beaucoup de problèmes à ces utilisateurs s'il n'y a pas de remplacement simple.

Je suppose que nous pourrions proposer quelque chose comme ceci comme chemin de migration :

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

@mantoni : Excellente suggestion. En attribuant simplement à la propriété test maintenant inutilisée, cela permet aux gens de réduire au minimum les tracas en incluant simplement une ligne supplémentaire dans leurs tests. Nous devons juste nous assurer que l'objet sinon n'est pas gelé (comme dans Object.freeze(sinon) ) à un moment donné ...

@jonnyreeves : concernant sinon.mock je me souviens que @mroderick a suggéré d'attendre la sortie de la 2.0 avant de supprimer cela. Nous avons déjà signalé depuis un certain temps qu'il était obsolète, il devrait donc être possible de le supprimer après la version 2.0 IMHO. Mais comme nous avons déjà le support CommonJS, cela ne me dérangerait pas de le supprimer avant la version 2.0 _si_ nous avons extrait le code dans un module qui lui est propre. Alors les gens pourraient juste let sinon.mock = require('sinon-mock') , s'ils le voulaient bien.

En ce qui concerne sinon.log* , je ne vois aucune raison de s'y accrocher en tant que fonctionnalités publiques si nous pouvions simplement les fournir en tant que configuration en cas de besoin.

WRT factorisant un sinon-test , notez simplement que nous aurions besoin de permettre aux consommateurs de fournir une configuration, c'est-à-dire :

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

ou similaire.

Je viens de repérer un autre changement d'API possible lors de la création d'un package sinon-test ; des idées sur ce qui devrait arriver à sinon.assert ? Encore une fois, cela ne me semble pas être une partie essentielle de l'API sinon et peut être mieux adapté en migrant vers un package sinon-test aux côtés de sinon.test et sinon.testCase ?

@fatso83 @mantoni @cjohansen; J'ai une version fonctionnelle d'un package sinon-test prêt à être examiné - l'un de vous pourrait-il initialiser un dépôt git vide à sinonjs/sinon-test afin que je puisse élever un PR contre celui-ci s'il vous plaît ?

Merci

C'était rapide! https://github.com/sinonjs/sinon-test

@cjohansen pourriez-vous simplement y

Terminé

Merci, PR soulevé - commentaires bienvenus : https://github.com/sinonjs/sinon-test/pull/1

@mroderick Si vous avez poussé le travail quelque part, faites-le moi savoir. Je pourrais peut-être t'aider avec la doc !

@spinningarrow ce serait génial. J'ai créé #991 pour suivre cela séparément du reste de l'effort. Je mettrai à jour cela dans les prochains jours avec mes réflexions, et nous pourrons partir de là.

Nous avons de temps en temps quelques problèmes liés aux simulations. Maintenant que @jonnyreeves a fait le dur travail d'extraction du module, ne serait-il pas logique de déplacer le module dans un référentiel s'il est le sien ? Ensuite, nous pourrions simplement déplacer toutes les discussions relatives aux simulations là-bas et clore les problèmes ici. Il s'agit principalement d'alléger la charge administrative.

Nous avons de temps en temps quelques problèmes liés aux simulations. Maintenant que @jonnyreeves a fait le dur travail d'extraction du module, ne serait-il pas logique de déplacer le module dans un référentiel s'il est le sien ? Ensuite, nous pourrions simplement déplacer toutes les discussions relatives aux simulations là-bas et clore les problèmes ici. Il s'agit principalement d'alléger la charge administrative.

Cela signifierait également une charge d'administration consistant à maintenir ce référentiel synchronisé avec les outils de développement, etc.
Peut-être devrions-nous nous assurer que nous avons d'abord configuré des outils de développement partagés faciles ? cc : @mantoni

@mroderick @fatso83 OK, voyons si nous pouvons sortir le 2.0.

J'ai mis à jour l'aperçu de ce problème pour couvrir ce que je considère être toutes les migrations en suspens (y compris CJSification de la suite de tests, s'il vous plaît, si vous lisez ceci - aidez-moi !) - veuillez jeter un œil et me faire savoir si vous êtes d'accord avec le travail remarquable.

De plus, j'aimerais obtenir un consensus sur les points suivants :

1. Doit-on supprimer typeOf et extend de l'API publique ( sinon. ), ou faut-il attendre Sinon 3.x qui (je suppose) subira une modernisation de l'API .
2. Devrions-nous supprimer la prise en charge/les hacks d'IE hérités de la version 2.0 ? Cela _peut_ simplifier la migration car nous pourrions supprimer le code 'fakeXDM' - je n'ai pas regardé de près donc je ne peux pas encore vraiment estimer ce travail.
3. L'expédition du nouveau site de documentation est-elle une condition préalable à la version 2.0 ? Je crains qu'il n'ait pas beaucoup de traction :)

Merci a tous.

@jonnyreeves : Vous avez certainement été une abeille occupée ce soir 😺. J'ai de longues vacances devant moi, donc je pourrais certainement aider avec les migrations exceptionnelles de la suite de tests (il y a un "mais" ci-dessous).

Concernant vos remarques :

1. Ils devraient partir. Je pensais que c'était à peu près réglé (réf, l'aperçu ci-dessus).
2. Définissons simplement « legacy IE » en premier. Versions < 10, ou l'ensemble du package sinon-ie ? IE9 était toujours livré avec une alternative CORS étrange appelée XDR. Si quelqu'un souhaite toujours prendre en charge les versions d'IE publiées avant 2012, il peut toujours utiliser la branche 1.x, je suppose. Vous ne savez pas à quoi vous faites référence par XDM ? Je ne sais pas pour quelles versions de navigateur sinon-ie sont nécessaires, donc je ne peux pas être trop catégorique sur le fait que le package n'est pas nécessaire. Nous devons être certains des conséquences.
3. La documentation _est_ un problème en ce moment, mais je ne sais pas trop quoi dire ici. Je pourrais commencer à creuser dans #991 avant d'aider avec les autres points ci-dessus. Avoir un endroit pour pousser les docs rendrait la vie meilleure.

Curieux de savoir quel est le statut à ce sujet ? On dirait qu'il n'y a pas eu beaucoup de progrès depuis ~6mo; Je dépend actuellement d'une pré-version pour diverses raisons (le support fonctionnel de Symbol étant énorme) - je ne veux pas pousser, mais un simple "il y a unchronologie' / 'il n'y a pas encore de chronologie' serait formidable ! <3

@ELLIOTTCABLE comme nous n'avons pas de financement, il n'y a pas de calendrier défini. Cela progresse au fur et à mesure que nous, dans le groupe des responsables - ou d'autres bénévoles comme vous-même - avons le temps de travailler sur la liste ci-dessus. Cela étant dit, je pense que vous auriez pu répondre vous-même à la question « statut » si vous aviez pris la peine de fouiller un peu plus 😉 :

1. Même si vous voyez "... référencé le 8 juillet 2016" ci-dessus, cela signifie seulement que le premier commentaire de la liste date de cette date. Le dernier numéro, #1235, faisait référence à "il y a 12 jours".
2. La liste des problèmes est presque complète - contrairement à il y a six mois.

Donc ... nous avançons quelque part, mais la supervision des corrections de bogues pour la version précédente, ainsi qu'un apport constant de nouvelles fonctionnalités, monopolisent une grande partie de notre temps de maintenance. Faire des recherches et écrire cela a pris une demi-heure à la fin 😅

Fondamentalement, après avoir examiné la liste ci-dessus, il ne reste que deux problèmes principaux :

• "Migration de fake_server et de ses amis" (résolu à 90 %, il ne reste qu'un petit peu - voir ci-dessus).
• Publier le site Web (voir #1220 : une chose mineure et super facile et une tâche moyenne à gagner)

Je pense que la plupart des autres coches de non-fermeture ci-dessus concernent les anciennes versions d'IE (6-10) dont je suis certain qu'elles ne seront pas prises en charge, sur la base des discussions dans #1221, elles peuvent donc être ignorées. J'y reviendrai maintenant.

@sinonjs/sinon-core : le commentaire précédent m'a fait prendre conscience que nous avons certains problèmes ci-dessus que nous ne pourrons probablement pas résoudre sur la base de la discussion dans #1221 :

1. Supprimer la prise en charge/solutions de contournement de Legacy IE ?
2. Correction de xdomain

Je me soucie de créer un PR pour simplement supprimer les bits IE hérités si nous ne les touchons pas de toute façon ? Je suppose que xdomain peut également se retrouver dans la décharge historique, car il s'agissait principalement d'un hack de type CORS uniquement pour IE, il peut donc être supprimé?

@fatso83 Ahhhh, k. J'ai manqué les commentaires mis à jour sur les problèmes référencés. J'espère que cet examen pour moi vous a été utile!

Sans rapport : On dirait qu'une partie de cela est l'abandon de la prise en charge d'IE6. C'est malheureux. Eh bien, c'est la marche du progrès ! /=

Nous sommes fondamentalement là, le site de docs a son propre problème.

Hé les gars - quelque chose nous empêche de marquer 2.0 comme la version "stable" sinon et de tuer 1.x? :)

Je pense que nous voulions que le #1297 soit la dernière chose.

ETA là-dessus ? Je suggère que nous expédions au plus tard la semaine prochaine, en reportant cette fonctionnalité si ce n'est pas fait.

Vous êtes beaux les gars. <3