Podcast: Téléchargement
Dans ce numéro, Fabrice, Antoine et Sébastien nous parlent d’une partie importante et souvent négligée du cycle de développement : les tests.
Les différents types de tests
- Tests unitaires voir aussi sur wikibooks
- Tests d’intégration
- Tests fonctionnels
- Tests d’acceptation (“UAT”)
- Tests de performance
- Tests d’intrusion
Comment ?
Test Driven Development & Pair Programming.
Les outils
- Tests unitaires : JUnit, TestNG, specs2, qunit, jasmine, mocha (javascript), OCUnit (ios), Infinitest
- Tests fonctionnels : selenium, PhantomJS / CasperJS
- Tests dans un container : arquillian
- Mocking : mockito, OCMock (ios)
- Performance : JMeter, gatling
Automatisation
- Dans le process de build : Maven ou grunt
- Dans l’intégration continue : Jenkins + Sonar
- Provisionning d’environnement pour les tests : vagrant, Chef / Puppet
Divers
- La vidéo de David Gageot à l’USI 2013
- Metasploit – Document et outils très complets pour les tests de pénétration.
- Pair Hero – Un plugin très sympathique pour rendre les tests unitaires ludiques.
Pour compléter les outils, un petit script perso que j’utilise tous les jours pour tester les appli web. Ce n’est rien de plus qu’un « profil manager » pour Chrome, il permet de créer un profil chrome à usage unique pour tester votre appli sans problème de cache,session,plugins… dans une nouvelle instance de browser toute fraiche (pour Mac OS X uniquement, désolé !) : https://github.com/adetante/chrome-profile-manager
Ce truc est merveilleux, merci!
C’est un succès mérité, continuez comme ça, c’est un podcast de qualité sur un sujet très interessant 🙂
Les développeurs détestent les tests ET faire la documenation 😉
Une vidéo interessant sur le developpement guidé par les tests http://soat.developpez.com/videos/java/developpement-dirige-par-les-tests-junit-mockito-refactoring-di/
C’est bien de coder à deux, mais ça coute 2x plus cher 🙁
A la rigueur un compromis serait de faire des réu toutes les semaines pour montrer ce qu’on a coder, plutot que de regarder ligne à ligne ce que code son collègue 😉
Dire que le pair programming coûte deux fois plus cher, je pense que c’est la même idée que dire que le temps qu’on passe à coder un test coûte plus cher. Si on prend un peu de recul, c’est du temps extrêmement bien investi.
Je trouve que l’idéal est d’identifier les zones sensibles de code et de forcer leur réalisation en pair programming. Ces algos « sensibles » seront bien plus matures, lisibles et maintenables. Et là, c’est coup double, le temps de base du développement soit disant doublé, va rapporter dans le futur des énormes gains de temps de maintenance.
Par contre dans notre quotidien, il y a aussi pas mal de code qui ne mérite pas de doubler les cerveaux et dans ce cas, il vaut mieux être seul. D’autre part, coder en pair programming est épuisant et il faut donc l’utiliser à bon escient.
Effectivement si le pair programming est ciblé sur un algo particulier ca peut valoir le coup 😉
Mais perso je veux bien coder à 2, c’est haut dessus qu’on me dira que ça coûte 2x plus cher 😉
On a l’habitude de faire un projet=un developpeur, alors si on doit doubler par projets. ..
Une petite rectification: David Gageot n’est pas le créateur du projet Infinitest mais il en est le mainteneur. Bravo à lui tout de même pour le boulot réalisé.
Super podcast ! Très complet sans être ennuyant 🙂
J’ai zapé le live, dommage 🙁
En parlant Pair Programming, j’ai trouvé la technique du ScreenCast plein écran très pratique pour apprendre une tecno.
– Je l’ai découvert avec les tutos de mattrunks
– Appliqué en « pro » pour passer l’info à des intégrateurs
– Et sur SARAH pour expliquer le développement de plugins
En parlant de Pentester, Korben a fait un super RemixJobs sur le métier:
http://www.nowatch.net/2012/01/remixjobs-6-le-metier-de-pentester/
Les screencast sont très pédagogue, c’est pour cela que j’en ai ajouté sur le site de mon framework: je n’arrivais pas a bien expliquer certaines choses à des utilisateurs, avec le screencast, pas d’ambiguité, on voit bien les fichiers éditer, et le resultat obtenu 😉
Pour les curieux : http://mkdevs.com/screencasts.html
Encore un excellent épisode merci!
Il y a ceux qui écoutent SoudCloud et les autres dont je fais partie… Il y a peut-être des millions d’auditeurs ? !
Super podcast en tout cas !
Je me dis qu’on peut mettre en place les tests unitaires dans une application qu’on reprend pour justement se l’approprier ? !
Pour la sécurité de mon framework je propose une page résumant les sécurités mises en place par celui-ci et celles à la charge du développeur: http://mkdevs.com/security.html
Dans les secteurs de la finance/banque en général, on utilise beaucoup les services de sociétés d’audit de sécurité 😉
Ne pas oubliez pour les DDOS que certaines directives de sécurité peuvent découler sur une DDOS: par exemple bloquer un compte au bout de N tentatives infructueuse, le hacker peut boucler sur les comptes utilisateurs pour tous les bloquer à un instant critique 🙁
Pour la sécurité, bien faire attention, quand j’entend « les frameworks vous protègent », je vous le dit : NON la plupart des frameworks ne protègent pas de tout, au mieux ils protègent de l’SQL injection avec les prepare statement et du XSRF avec les jetons. Mais le XSS/null byte, pour Zend Framework 1.* et Yii: NON. C’est un vrai travail différent de faire un framework qui protège efficacement de ce type d’attaque (c’est le cas du mien profitant de mon expérience en sécurité)
Sur demande, je peux vous faire un test de sécurité sur le site de votre choix 😉
Mais je le répète pour la sécurité le mieux est de faire appel avant la mise en production à une société d’audit de sécurité dont c’est le travail 😉