Comments on: Un gros guide bien gras sur les tests unitaires en Python, partie 2

By: srjjio

srjjio — Wed, 20 Sep 2017 09:38:24 +0000

Je me demande bien pourquoi unittest est écrit en camel case… OK, initialement c’est un portage de JUnit donc y’avait probablement la volonté de conserver le formalisme, mais de là a ne pas adapter la syntaxe c’est moche non ?

By: Samson

Samson — Sat, 22 Mar 2014 08:24:16 +0000

C’est balot :) Mais comme c’est un service externe, on va pas se casser la tête dessus.

Je comprends. Mais le pire ou le mieux, c’est qu’hier dans un ultime essais, cela à fonctionné. Alors que j’essayé depuis plusieurs jours : oui quand je suis obstiné, je le suis très bêtement. J’ai même cru à une intervention magique voir même divine de votre part (j’attendais votre confirmation)… Et aujourd’hui ça ne fonctionne plus ; je m’en fous je l’ai maintenant… Bon, cela reste tout aussi magique ; à moins qu’à mon insu je sois victime de puissante substances douteuses !!!

Merci pour votre réponse et surtout merci pour votre site.

By: Sam

Sam — Fri, 21 Mar 2014 15:02:29 +0000

C’est balot :) Mais comme c’est un service externe, on va pas se casser la tête dessus.

By: Samson

Samson — Fri, 21 Mar 2014 09:37:48 +0000

Bien que l'on puisse voir en ligne cette partie 2 dans "readability.com", il est impossible de la récupérer en "epub". On récupère invariablement la partie 1 au lieu de la 2. Est-ce à cause de la virgule dans le titre qu'il confond les deux parties ?? En tout cas les deux parties de "Comprendre les décorateurs Python pas à pas" : (partie 1) et (partie 2) fonctionnent très bien. On peut toutes les deux les récupérer en epub.

By: cendrieR

cendrieR — Mon, 10 Mar 2014 03:25:27 +0000

Vivement la suite :)

By: gontran

gontran — Thu, 20 Feb 2014 07:07:30 +0000

@Sam : Ok. J’avais cherché pendant pas mal de temps un moyen de faire ça au niveau de la classe, plutôt qu’au niveau des méthodes.

Ca me parait quand même plus logique dans un contexte objet.

By: Sam

Sam — Wed, 19 Feb 2014 06:15:11 +0000

@Gontran : Non, c’est normal. Tu peux accélérer les tests en mettant ta base de données en mémoire vive, ou alors utiliser py.test qui a des setup/teardown plus modulaire avec pytest-django.

By: Sam

Sam — Wed, 19 Feb 2014 06:09:13 +0000

Les prochaines parties traiteront py.test, les docstring, les tests django et aussi, même si c’est pas le sujet, les tests end to end et les tests fonctionnels. Y a du taff, je vous dis pas.

By: kontre

kontre — Tue, 18 Feb 2014 23:29:01 +0000

Clair que py.test (ou nose) sont plus simple à utiliser. Unittest a pour lui d’être inclus dans python de base, et de bien montrer les dessous des tests unitaires. Les assertEqual sont plus faciles à expliquer que la magie de py.test pour retrouver les valeurs de variables dans assert a == b.
Donc partir sur unittest ça me parait logique, mais j’espère que Sam a prévu de présenter les principaux frameworks dans la suite.
Y’a aussi les doctests…

By: OKso

OKso — Tue, 18 Feb 2014 15:43:28 +0000

Sinon, avec py.test, on se fait pas chier avec toutes ces classes à la con et ces “self.assertEqual(…)”. Des fonctions plates et le mot-clef ‘assert’ sont beaucoup plus simples à utiliser, et du coup ça motive à les faire.

Je m’immagine pas devoir expliquer toute la POO pour pouvoir expliquer comment créer un bête test unitaire à un pote…