Imaginez un combat homérique entre les forces du bien et du mal, luttant pour la domination du monde. Dans le camp des forces du mal : la procrastination, Internet Explorer et les cycles en V ; dans le camp des forces du bien : Python, le café et les tests automatisés.
Tout le monde aujourd'hui est d'accord pour dire qu'écrire des tests est probablement la tâche la plus efficace quand il s'agit de garantir un code robuste et maintenable. (Enfin, presque tout le monde ; ceux qui dénigrent les tests sont en général ceux qui sont trop flemmards pour en écrire.)
À ce titre, Django se montre exemplaire, et la documentation relative aux tests est aussi complète que détaillée. Seulement voilà, quiconque a déjà travaillé sur un projet Django pendant plus de quelques semaines sait que de nombreuses questions sont laissées de côté. Et notre développeur / testeur est réduit à parcourir les bas-fonds du web pour trouver réponse à ses questions.
Comment écrire une suite de tests maintenable ?
Comment tester des fonctionnalités qui utilisent javascript intensément ?
Comment tester des fonctionnalités qui font appel à des web services et sont fortement couplés ?
Comment être certain que les tests qui tournent sur ma machine fonctionneront aussi sur la prod ?
Sans plus tarder, voici quelques réponses à ces questions.
Je vous l'avoue, je suis actuellement bien embêté, car j'ai un facheux problème de vocabulaire. C'est un ennui qui revient de façon récurrente, et notamment lorsque l'on me demande innocemment quel est mon métier.
D'apparence, cette question est trés banale et innocente, presqu'au point de me laisser soupçonner une certaine simplicité d'esprit de la part de son auteur.
Étant développeur freelance et travaillant à domicile, mes facultés sociales ont connu un déclin lent mais inexorable au cours des derniers mois. C'est sans doute pour cette raison que socialiser avec de parfaits inconnus ne m'apporte qu'un intérêt trés limité, et je me contente en général de répondre à la question suscitée par un vague grognement guttural dans lequel on peut reconnaître, si l'on est attentif, les mots « Beuarrrrr je fais des sites web… ».
Il y a quelques jours, alors que je bossais sur mon pet project du moment, je
me suis surpris à penser « tiens, ça serait bien si cette fonctionnalité
devenait une application Django réutilisable ». La fonctionnalité en
question ne nécessitant pas plus de quelques lignes, je me suis dit que ce
serait rapidement torché.
Le fait que je me retrouve 10 jours plus tard et deux applications
supplémentaires me prouve encore une fois que je suis vraiment mauvais avec les
estimations. Et on s'étonne que je ne travaille pas au forfait …
Quoi qu'il en soit, pour la dernière app, j'ai décidé de tester l'approche
Documentation Driven Development. Retours d'expérience.
Et si je vous disais que la lecture d'un seul billet sur le Web pouvait vous faire gagner des milliers, voire dizaines de milliers d'euros ?
« Diantre, me répondriez-vous ! Une affirmation aussi péremptoire ne pourrait que relever de la réclame la plus sordide ! Un tel billet constituerait à coup sûr un abject prostitulien, indigne de l'urbanité qui règne habituellement en ces lieux ! »
Et pourtant ! pourtant ! je n'aime que toi Je ne peux peut-être pas vous faire gagner de telles sommes, en revanche je peux sûrement vous aider à ne pas les perdre !
Le billet qui suit est une nouvelle Polargeek et
s'étend sur 7300 mots ; son temps de lecture est estimé aux alentours de 20 à
30 minutes. Vous pouvez aussi la télécharger aux formats
pdf,
epub et
mobi. Bonne
lecture.
Si vous n'avez pas vécu sur une branche d'arbre les dix dernières années, vous
savez probablement que le concept de vie privée est quelque peu chahuté ces
derniers temps.
J'écoute de la musique, et j'aime ça ; mais je n'y connais rien à la musique.
Un jour, je me suis dit « tiens, ça serait cool d'essayer d'écrire de la
musique ». J'ai ouvert un nombre incalculables de sites et livres portants sur
la théorie musicale, et je les ai refermés avec l'impression d'être un parfait
demeuré.
Ce texte est la transcription de la conf donnée à Paris Web. Le texte contient donc des tics de langages et du mauvais français. Vous êtes prévenu-e-s.
Construire ou faire construire des logiciels reste encore aujourd'hui une
entreprise hasardeuse. D'autant plus lorsqu'on utilise des méthodes de travail
qui ne sont pas adaptées.
