Relecture: Testing Behaviour

[Antoine Cezar]

Salut tout le monde.

Je prépare un article sur un cas qui m'est arrivé récemment. J'aimerai vos avis sur ce que j'ai écrit: http://antoine.cezar.fr/testing-behaviour.html

[Gregory Salvan]

Salut,

sur le fait de tester la sortie plutôt que l’état interne 👍

Par contre le slice risque de te créer des problèmes, par exemple si tu as des références arrières...

C'est pour quel usage ton parseur ?

Le 13 janvier 2018 à 21:02, Antoine Cezar <antoin...@gmail.com> a écrit :

Salut tout le monde.

Je prépare un article sur un cas qui m'est arrivé récemment. J'aimerai vos avis sur ce que j'ai écrit: http://antoine.cezar.fr/testing-behaviour.html

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Software Craftsmanship Toulouse".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse software-craftsmanship-toulouse+unsubscribe@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Antoine Cezar]

Il faudra en effet que je puisse revenir en arrière. Mais je peux tester ça en vérifiant ce qui sort du consume_string après un backtrack.

C'est pour remplacer celui que j'ai dans https://github.com/AntoineCezar/chordchart-notation

[Olivier Azeau]

Salut,

Non seulement la première mouture teste un état interne, mais, en plus, elle ne garantit pas grand chose.
Si on fait pas trop gaffe, on peut se retrouver avec une implémentation qui passe le test de l'état interne mais plante sur le test qui consomme la suite de la chaine.
J'ai joint un exemple mais je ne sais pas si les fichiers passent dans googlegroups. (j'ai juste remplacé "result.append(string)" par "result.append(self._string[:len(string)])" dans l'implémentation initiale)

En allant plus loin dans la réflexion, je dirais que ce qui compte, ce n'est pas tant de tester un état ou un comportement mais de tester un cas d'usage réel.
Je considère que les tests d'une classe doivent ressembler au code que l'on va écrire quand on va effectivement utiliser la classe en question. Dans le cas présent, j'imagine que le code client se soucie plus du contenu du résultat que de l'état de l'index.

Olivier

Le 13/01/2018 à 21:02, Antoine Cezar a écrit :

Salut tout le monde.

Je prépare un article sur un cas qui m'est arrivé récemment. J'aimerai vos avis sur ce que j'ai écrit: http://antoine.cezar.fr/testing-behaviour.html

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Software Craftsmanship Toulouse".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse software-craftsmanshi...@googlegroups.com.

[Gregory Salvan]

> tester un cas d'usage réel

c'est particulièrement vrai pour le parsing  ou il y a une multitude d'algorithmes possibles et connus en fonction du problème que tu veux résoudre.

Dans le cas ou tu veux implémenter un algorithme en particulier, est-ce que ça vous semble raisonnable que les tests décrivent l'algorithme plutôt que des cas d'usage réels (l'un n’empêche pas l'autre) ?

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse software-craftsmanship-toulouse+unsubscribe@googlegroups.com.

Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Software Craftsmanship Toulouse".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse software-craftsmanship-toulouse+unsubscribe@googlegroups.com.

[Antoine Cezar]

J'ai volontairement simplifié l'exemple, mais il y a d'autres tests dont un qui couvre déjà l'erreur que tu propose. C'était d'ailleurs le premier test: vérifier la valeur obtenue quand je consomme. Le test que je met en lumière dans l'article c'est le second: vérifier qu'on avance bien dans le text. Mais c'est vrai que du coup la nouvelle version du test est plus solide. Je vais voir comment intégrer ça dans l'article. Merci pour tes remarques.

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse software-craftsmanship-toulouse+unsubscribe@googlegroups.com.

[Antoine Cezar]

En fait je n’implémente pas d'algo en particulier. Juste celui que j'ai découvert en cherchant comment parser mon propre DSL. Il se trouve que c'est un recursive descent parser, mais je l'ai découvert après coup. J'ai juste implémenté la manière dont je parsai mentalement le texte.

Si j’implémentai un algo particulier, j'aurai sans doute des tests à la fois pour le comportement et l'algo en effet.

[Gregory Salvan]

Ça me rappelle une discussion sur l'implémentation des algorithmes il y a quelques années sur le groupe SCT global. La conclusion était que la conception émergente n'excluait pas une phase de recherche ou réflexion amont et donc qu'il était possible d'implémenter un algorithme précis sans tomber dans le Big design up front.

Perso, je suis plus à l'aise en BDD qu'en TDD pour faire ça, car en TDD tu vas plutôt tester les extremums ce qui ne décrit pas toujours très bien l'algo alors qu'en BDD tu vas tester les interactions entre tes objets. Lorsque ça devient complexe je découpe en événements afin de faire ressortir ces interactions.

A mon avis, un cas caractéristique de BDD c'est quand tu vérifies des appels méthodes. Par exemple tu pourrais vouloir tester que startswith est appelé pour mettre en valeur la possibilité d'utiliser le polymorphisme et caractériser l'objet qui est parsé. (évidemment une chaine de caractère mais tu pourrais avoir des types différents en fonction de l'encodage... )

Je travaille actuellement sur un algorithme de parsing parallèle en Julia, si ça t'intéresse je pourrai te montrer du code.

Bonne continuation, amusez-vous bien.

Le 14 janv. 2018 1:39 PM, "Antoine Cezar" <antoin...@gmail.com> a écrit :

En fait je n’implémente pas d'algo en particulier. Juste celui que j'ai découvert en cherchant comment parser mon propre DSL. Il se trouve que c'est un recursive descent parser, mais je l'ai découvert après coup. J'ai juste implémenté la manière dont je parsai mentalement le texte.

Si j’implémentai un algo particulier, j'aurai sans doute des tests à la fois pour le comportement et l'algo en effet.

Le dimanche 14 janvier 2018 00:53:40 UTC+1, Grégory Salvan a écrit :

> tester un cas d'usage réel

c'est particulièrement vrai pour le parsing  ou il y a une multitude d'algorithmes possibles et connus en fonction du problème que tu veux résoudre.

Dans le cas ou tu veux implémenter un algorithme en particulier, est-ce que ça vous semble raisonnable que les tests décrivent l'algorithme plutôt que des cas d'usage réels (l'un n’empêche pas l'autre) ?

Le 13 janvier 2018 à 23:25, Olivier Azeau <olivie...@gmail.com> a écrit :

Salut,

Non seulement la première mouture teste un état interne, mais, en plus, elle ne garantit pas grand chose.
Si on fait pas trop gaffe, on peut se retrouver avec une implémentation qui passe le test de l'état interne mais plante sur le test qui consomme la suite de la chaine.
J'ai joint un exemple mais je ne sais pas si les fichiers passent dans googlegroups. (j'ai juste remplacé "result.append(string)" par "result.append(self._string[:len(string)])" dans l'implémentation initiale)

En allant plus loin dans la réflexion, je dirais que ce qui compte, ce n'est pas tant de tester un état ou un comportement mais de tester un cas d'usage réel.
Je considère que les tests d'une classe doivent ressembler au code que l'on va écrire quand on va effectivement utiliser la classe en question. Dans le cas présent, j'imagine que le code client se soucie plus du contenu du résultat que de l'état de l'index.

Olivier

Le 13/01/2018 à 21:02, Antoine Cezar a écrit :

Salut tout le monde.

Je prépare un article sur un cas qui m'est arrivé récemment. J'aimerai vos avis sur ce que j'ai écrit: http://antoine.cezar.fr/testing-behaviour.html

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Software Craftsmanship Toulouse".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse software-craftsmanship-toulouse+unsu...@googlegroups.com.

Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Software Craftsmanship Toulouse".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse software-craftsmanship-toulouse+unsu...@googlegroups.com.

Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.