Tester

Bien qu'en construction, cette page vise à regrouper des informations sur les pratiques de tests logiciels.

Généralités

• Texte général mais bien documenté sur la question des tests dans le développement logiciel, par Adam Petersen et Seweryn Habdank-Wojewodzki en 2012 : http://www.adampetersen.se/articles/developmentfuel/DevelopmentFuel.htm
• Développer une expertise dans le domaine des tests, un texte de Pradeep Soundararajan en 2011 : http://blog.softwaretestingclub.com/2011/04/becoming-an-expert-in-testing-without-working-hard-and-in-8-simple-steps/
• Comment réaliser des tests dans une entreprise de l'ampleur de Google, un texte de 2011 : http://google-engtools.blogspot.com/2011/06/testing-at-speed-and-scale-of-google.html
• De manière plus générale, une réflexion sur la question de l'ampleur et de l'exhaustivité des tests à réaliser, par Martin Fowler en 2012 : http://martinfowler.com/bliki/TestCoverage.html
• Tester en collaborant avec le « Singe du chaos », un texte de 2011 : http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html
• Différents styles de tests, selon Ramiro Rinaudo en 2011 : http://blogs.mulesoft.org/the-developer-testing-paradox/
• Il vient un temps où les tests frappent un point de rendements décroissants, selon David Tobey en 2011 : http://www.softslate.com/blog/2011/08/testing-has-a-point-of-diminishing-returns.html
• Répertoire de ressources à propos de l'assurance-qualité et des tests : http://www.softwareqatest.com/
• La psychologie des tests : http://www.codeproject.com/KB/bugs/Pratap.aspx
• Une fable sur les tests, texte de 2010 : http://googletesting.blogspot.com/2010/07/code-coverage-goal-80-and-no-less.html
• Une réflexion d'ensemble sur les tests et leur rôle dans le cycle de développement, par Sam Hugues en 2011 : http://qntm.org/test
• Et si les lois étaient testées avant d'être votées? Une opinion de Rebecca Tuhus-Dubrow en 2010 : http://www.boston.com/bostonglobe/ideas/articles/2010/12/12/law_lab/?page=full
• Les spécifications, sans tests, sont inutiles, selon Bruce Eckel, un texte de 2009 : http://www.artima.com/weblogs/viewpost.jsp?thread=265376
• Ce n'est pas tant l'écriture de tests que l'écriture d'histoires, selon Misko Hevery en 2009 : http://misko.hevery.com/2009/09/02/it-is-not-about-writing-tests-its-about-writing-stories/
• Comment écrire du code impossible à tester? http://googletesting.blogspot.com/2008/07/how-to-write-3v1l-untestable-code.html
• Cinq raisons d'écrire des tests pour notre propre code, un texte de 2011 : http://masternerd.lucianocheng.com/5-reasons-for-testing-masternerdposterouscom
• Comment écrire du code facile à tester?
  • un texte de Isa Goksu en 2010 : http://www.methodsandtools.com/archive/archive.php?id=103
  • un texte de John Socha-Laialoha en 2011 : http://blogs.msdn.com/b/jsocha/archive/2011/07/12/building-for-testability-in-c.aspx
  • écrire des classes « testables », selon Andrew Binstock en 2011 : http://blog.coderscabal.org/2011/06/07/great-article-on-testibility-and-class-design/
  • mieux vaut réduire les strates des tests, de l'avis d'Andy Balaam en 2015 : http://accu.org/index.php/journals/2108
• Jeff Kreeftmeijer, dans un texte de 2011, suggère de cesser de publier des prototypes et d'attendre de savoir ce que l'on fait avant de proposer un produit : http://jeffkreeftmeijer.com/2011/stop-releasing-prototypes/
• Réaliser des tests où existe une dépendance envers le temps avec C#, un texte de Craig Gidney en 2013 : http://twistedoakstudios.com/blog/Post3516_rule-of-thumb-ask-for-the-clock
• Dans une optique connexe, Jakub Holý, dans un texte de 2012, relate son expérience de programmation avec Kent Beck : http://blog.iterate.no/2012/06/20/programming-like-kent-beck/
• Tests en boîte noire ou en boîte blanche :
  • décrits par Santosh Behura en 2011 : http://activeclass.blogspot.com/2011/01/black-white-box-testing.html
  • un comparatif, selon Viktor Farcic en 2013 : http://technologyconversations.com/2013/12/11/black-box-vs-white-box-testing/
  • impact sur les mesures de complexité, un texte de Dick Lipton et Ken Regan en 2014 : http://rjlipton.wordpress.com/2014/02/08/black-versus-white-boxes/
• Trouver l'équilibre entre la productivité et la qualité, d'un point de vue Ruby, par Gregory Brown en 2011 : http://blog.rubybestpractices.com/posts/gregory/050-issues-18-testing-dogma.html
• Vérifier a priori l'intérêt pour un produit, à l'aide du Pretotyping, une idée d'Alberto Savoia en 2011 : http://googletesting.blogspot.com/2011/08/pretotyping-different-type-of-testing.html
• En 2011, Andrew Glover suggère d'utiliser des outils d'aide aux tests, mais de ne pas se fier aveuglément sur eux : http://www.ibm.com/developerworks/java/library/j-cq01316/
• Tests et échelonnabilité (Scalability), une réflexion de Jared Carroll en 2011 : http://blog.carbonfive.com/2011/09/19/testing-doesnt-scale/
• Les métriques sont-elles pertinentes? Le point de vue d'Andrew Binstock en 2011 : http://drdobbs.com/architecture-and-design/231602262
• Imposer un standard de qualité sur les blogues s'adressant aux programmeurs? Une proposition de Wesley Tansey en 2011 : http://www.nashcoding.com/2011/10/28/hackernews-needs-honeypots/
• Selon Aviv Ben-Yosef, en 2011, le temps est venu « d'arrêter de se plaindre et d'écrire ces satanés tests » : http://www.codelord.net/2011/11/28/stop-bitching-write-those-damn-tests/
• Accélérer les tests en les parallélisant, une proposition d'Igor Afonov en 2012 : http://iafonov.github.com/blog/parallel-tests.html
• Tester, soit, mais quoi? Le point de vue de Kresimir Bojcic en 2012 : http://kresimirbojcic.com/2012/04/04/what-to-test.html
• À propos des types de testeurs et des types de tests, une réflexion de Larry Osterman en 2004 : http://blogs.msdn.com/b/larryosterman/archive/2004/09/23/233531.aspx
• Adapter les pratiques de tests sur le matériel au monde du logiciel, texte de 2012 : http://www.dodgycoder.net/2012/06/applying-hardware-testing-concepts-to.html
• Réflexion de Bertrand Meyer en 2012 sur les limites inhérentes aux tests : http://bertrandmeyer.com/2012/10/14/a-fundamental-duality-of-software-engineering/
• L'assurance-qualité doit évoluer, de l'avis de Martin Anderson en 2012 : http://bloodredsun.com/2012/10/23/why-qa-needs-to-change/
• Tester des systèmes complexes, par Gigi Sayfan :
  • en général : http://www.drdobbs.com/testing/testing-complex-systems/240008913
  • quand ils sont rédigés en C++ : http://www.drdobbs.com/cpp/testing-complex-c-systems/240147275?pgno=1
• Distinguer les mocks, les stubs et les fakes, un texte d'Andrew Trenk en 2013 : http://googletesting.blogspot.ca/2013/07/testing-on-toilet-know-your-test-doubles.html
• Devrait-on préférer les tests ou les preuves pour valider le logiciel? Texte de 2013 : http://www.hxa.name/notes/note-hxa7241-20130804T0939Z.html
• En 2013, Vic Cherubini explique pourquoi et en quoi sa philosophie personnelle quant aux tests a changé : https://leftnode.com/entry/my-philosophy-on-testing-has-changed.html
• Réussir ses tests automatisés, un texte de 2013 par Guðni Ólafsson : http://blog.olafssons.com/post/How%20not%20to%20screw%20up%20your%20automated%20testing
• De meilleures techniques de tests manuels, article de 2013 par Rubeena Basheer : http://www.leaseweblabs.com/2013/12/testing-techniques-better-manual-testing/
• Est-ce sage de rédiger des tests pour des systèmes hérités? Opinion de Stephen Haunts en 2013 : http://stephenhaunts.com/2013/11/19/is-it-a-good-idea-to-write-tests-for-legacy-code/
• Des bons et des moins bons tests, texte de James O'Beirne en 2013 : http://jameso.be/2013/11/16/good-tests.html
• Utiliser des tests d'acceptance à titre de spécifications, selon Bart Bakker en 2013 : http://blog.thesoftwarecraft.com/2013/12/acceptance-tests-as-specifications.html
• Texte de 2014 par Craig Gidney, portant sur le biais positif (tendance à vérifier les succès plutôt que les échecs) dans les tests : http://strilanc.com/testing/2014/03/18/Positive-Bias-and-Testing.html
• Texte de 2014 par Ashton Kemerling qui préconise des tests génératifs : http://www.pivotaltracker.com/community/tracker-blog/generative-testing
• L'importance des tests dans une démarche de programmation menant à des programmes presque exempts de bogues, perspective d'Edsger Dijkstra décrite du point de vue d'Eric Potter en 2014 : http://blog.apterainc.com/bid/386640/Unit-Testing-Days-of-Future-Past-for-Software-Development
• Le Risk-Driven Testing, une idée de Peter Arrenbrecht en 2014 : http://googletesting.blogspot.nl/2014/05/testing-on-toilet-risk-driven-testing.html
• En 2011, Ian Cooper est d'avis qu'il vaut mieux tester des comportements que des détails d'implémentation : http://codebetter.com/iancooper/2011/10/06/avoid-testing-implementation-details-test-behaviours/
• Texte de Stefanus Du Toit en 2014 sur ses réactions émotives au code de qualité (ou de moindre qualité), aux outils bien ou moins bien faits, et à l'écriture de tests : http://blog.sduto.it/2014/06/emotions-and-programming.html
• Devrait-on placer de la logique dans le code de test?
  • Selon Erik Kuefler en 2014, mieux vaut l'éviter, pour éclaircir le propos : http://googletesting.blogspot.ca/2014/07/testing-on-toilet-dont-put-logic-in.html
  • Selon Edaqa Mortoray en 2014, oui, pour faciliter leur entretien : http://mortoray.com/2014/08/01/counterargument-dont-put-logic-in-tests/
• Quelle est la véritable valeur de tests automatisés? Réflexion de Kent Anderson en 2014 : http://www.kornerstoane.com/2014/08/the-real-value-of-writing-automated-tests/
• En 2014, Chris Kottom explique pourquoi il fait des tests : http://chriskottom.com/blog/2014/08/why-i-test/
• En quoi les interfaces de Go facilitent la rédaction de tests, selon John Graham-Cumming en 2014 : http://blog.cloudflare.com/go-interfaces-make-test-stubbing-easy
• Il est essentiel que les tests ne ralentissent pas le processus de développement, selon Robert C. Martin en 2014 : http://blog.cleancoder.com/uncle-bob/2014/09/03/TestTime.html
• Le « mode chaos », une manière de générer des cas d'erreurs autrement difficiles à obtenir, par Robert O'Callahan en 2014 : http://robert.ocallahan.org/2014/03/introducing-chaos-mode.html
• Le point de vue d'un « testeur » sur le film Jurassic Park, par Jeremy Wenisch en 2015 : http://testersnotebook.jeremywenisch.com/2015/02/26/bugs-find-a-way-a-testers-appreciation-of-jurassic-park/
• Nous sommes trop doux avec notre code, ce qui le rend fragile, comme le rappelle Jeff Atwood en 2015 : http://blog.codinghorror.com/doing-terrible-things-to-your-code/
• À propos de la fragilité de tests faits selon une approche agile, texte de 2015 : http://blog.craftingagile.com/2015/05/26/fragile-agile-testing/
• Aspects psychologiques de la mise en place une approche de test qui aura du succès, par Andrew Anderson en 2015 : http://conversionxl.com/the-psychology-of-a-successful-testing-program/
• Vous ne savez pas si votre infrastructure de tests fonctionne correctement si vos tests n'ont jamais échoué, comme le souligne Bozhidar Bozhanov en 2015 : http://techblog.bozho.net/make-tests-fail/
• À propos de l'importance des tests, par Matt Asay en 2015 : http://readwrite.com/2015/08/12/good-code-testing

Qualité

• Qui détermine la qualité d'un logiciel? Est-ce le client ou les programmeuses et les programmeurs? Opinion de Cory House en 2014 : http://www.bitnative.com/2014/01/28/who-chooses-quality-client-or-coder/
• Pour atteindre un meilleur niveau de qualité, mieux vaut ralentir le rythme et faire des choses simples, selon Brad Bollenbach en 2014 : http://bugroll.com/slow-down.html
• Écrire du logiciel qui sera prêt pour « le monde », par exemple prêt pour l'internationalisation. Texte de Brian Kelly en 2014 : http://morethancoding.com/2014/05/20/how-to-write-software-that-is-ready-for-the-world/
• Trucs pour écrire du code de qualité, par Diomidis Spinellis en 2014 : http://www.informit.com/articles/article.aspx?p=2223710
• Quelques symptômes de logiciel de faible qualité, selon Hugo Baraúna en 2014 : http://blog.plataformatec.com.br/2014/06/the-symptoms-of-low-internal-software-quality/
• Textes de Steve Rowe en 2014 :
  • il faut distinguer la qualité objective de la qualité perçue : http://blogs.msdn.com/b/steverowe/archive/2014/06/23/perceived-vs-objective-quality.aspx
  • nous avons perdu l'essentiel en mettant l'accent de nos tests sur le fait que le produit soit correct, pas sur le fait qu'il s'agisse d'une produit de qualité : http://blogs.msdn.com/b/steverowe/archive/2014/06/09/test-has-lost-its-way.aspx

Programmation orientée par les tests (Test-Driven Development, TDD)

• Réaliser de meilleurs jeux grâce au TDD, selon Noel Llopis en 2006 : http://gamesfromwithin.com/backwards-is-forward-making-better-games-with-test-driven-development
• Le TDD détruit les architectures logicielles après une troisième itération, selon Cédric Beust en 2008 : http://beust.com/weblog/2008/03/03/tdd-leads-to-an-architectural-meltdown-around-iteration-three/
• Le TDD ne serait pas sage lorsqu'on apprend un nouveau langage, selon Peter Evjan dans un texte de 2011 : http://peterevjan.com/posts/7
• En 2011, Peter Sergeant critique le TDD fait sans réfléchir : http://www.writemoretests.com/2011/09/test-driven-development-give-me-break.html (suite sur http://www.modernperlbooks.com/mt/2011/09/always-tdd-except-when-you-shouldnt.html)
• Le TDD en pratique, selon Len Holgate depuis 2004 (une série d'articles qui se poursuit, au moment d'écrire ces mots) : http://www.lenholgate.com/blog/2004/05/practical-testing.html
• En 2011, Jacob Proffitt se demande à quel point le TDD est efficace : http://theruntime.com/blogs/jacob/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx
• Développement Test-Driven ou développement Test-First, un texte de Noam Kfir en 2012 : http://noam.kfir.cc/blog/2012/03/10/test-driven-and-test-first-development?ppt=c095cc734be521cd8f484d7c43fababf
• Appliquer cette technique efficacement, un texte de 2012 : http://37signals.com/svn/posts/3159-testing-like-the-tsa
• Le TDD appliqué au développement en langage d'assemblage, un texte de Michael Baker en 2012 : http://blog.8thlight.com/michael-baker/2012/06/07/test-driven-assembly.html
• Appliquer le TDD aux systèmes embarqués développés en langage C, par Yohei Onishi en 2012 : http://legobokueng.blogspot.jp/2012/07/tdd-for-embedded-c-introducing-runtime.html
• De l'avis de Denis Defreyne en 2013, le TDD peut changer la manière dont on abordera un problème : http://stoneship.org/essays/tdd-bypasses-your-brain/
• En 2014, Andrew Koening clame que le TDD est une grande avancée dans la pratique de la programmation, mais questionne son utilité dans la détection de bogues de « performance », au sens large de vitesse d'exécution et de débit de traitement, de même que des bogues découlant d'un non-respect de la complexité algorithmique attendue : http://www.drdobbs.com/cpp/performance-bugs-not-just-hard-to-detect/240164448
• Du TDD généré à la compilation à partir du code source, selon Eric Rasmussen en 2014 : http://chromaticleaves.com/posts/idris-and-dependent-types.html
• Les risques associés au TDD, selon Cédric Beust en 2014 : http://beust.com/weblog/2014/05/11/the-pitfalls-of-test-driven-development/
• En quoi le TDD peut aider à réduire une « dette technique », texte de Henrik Kniberg en 2013 : http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt#!
• Rappel que TDD n'est qu'un outil, par Shaun Finglas en 2014 : http://blog.shaunfinglas.co.uk/posts/2014/02/test-driven-developoment-is-a-tool
• TDD n'est pas une religion, texte de 2014 : http://th3james.github.io/blog/2014/05/17/tdd-is-a-feedback-tool/
• Appliquer TDD à une API, par Steve Klabnik en 2014 : http://blog.balancedpayments.com/tdd-your-api/
• Utiliser TDD avec un peu de bon sens, texte de Jay Conway (je pense) en 2014 : http://blog.jaywayco.co.uk/?p=144
• En 2014, J. B. Rainsberger explique en quoi le TDD influence ses designs : http://blog.thecodewhisperer.com/2014/05/22/how-tdd-affects-my-designs
• Dans ce texte de 2014, Martyn Frank distingue les problèmes inhérents à TDD de ses propres erreurs : https://frankcode.wordpress.com/2014/07/01/tdd-where-did-i-go-wrong/
• Conséquences du TDD sur les testeurs, par Duncan Nisbet en 2014 : http://www.ministryoftesting.com/2014/08/tdd-testers/
• Dans ce texte de 2014, David Banham affirme que « vous faites déjà du TDD » : http://blog.davidbanham.com/articles/tdd/
• Faire du TDD en se basant strictement sur des propriétés, texte de Nat Pryce en 2015 : http://www.natpryce.com/articles/000807.html
• Appliquer TDD à du code hérité mais qui n'a pas été testé rigoureusement par le passé, réflexions de Norbert Csibra en 2015 : http://www.javacodegeeks.com/2015/02/thoughts-about-tdd-and-how-to-use-it-for-untested-legacy-code.html
• Appliquer le TDD aux systèmes embarqués à l'aide de C++, présentation de James W. Grenning en 2015 : https://www.wingman-sw.com/slides/tdd-embedded-grenning-NCD-2015.pdf
• Vladimir Khorikov exprime, dans ce texte du Code Project en 2015, l'opinion que TDD peut endommager le design s'il est mal appliqué : http://www.codeproject.com/Articles/1015554/Test-induced-design-damage-or-why-TDD-is-so-painfu
• S'adonner au TDD en langage C, texte de 2014 : http://ryepdx.com/2014/09/tdd-in-c/
• Abandonner le TDD, par Ian Sommerville en 2016 : http://iansommerville.com/systems-software-and-technology/giving-up-on-test-first-development/
• Réflexions de Robert C. Martin :
  • le TDD pragmatique, texte de 2013 : http://blog.8thlight.com/uncle-bob/2013/12/10/Thankyou-Kent.html
  • le TDD monogame, texte de 2014 : http://blog.8thlight.com/uncle-bob/2014/04/25/MonogamousTDD.html
  • que faire quand TDD ne fonctionne pas? Texte de 2014 : http://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work
  • les cycles du TDD, texte de 2014 : http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html
  • texte de 2010 (et adapté en 2013) sur l'impact des tests sur la façon de programmer : http://blog.8thlight.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html
  • abandonner l'approche TDD pour les mauvaises raisons, texte de 2016 : http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTDD.html
    • réplique de Itamar Syn-Hershko en 2016 : http://code972.com/blog/2016/04/96-giving-up-on-tdd
• Réflexions de Kent Beck :
  • dans ce texte de 2014, il réfléchit aux cas où TDD n'importe que peu ou pas : https://www.facebook.com/notes/kent-beck/when-tdd-doesnt-matter/797644973601702
  • mêler TDD est programmation fonctionnelle entraîne une sorte de choc des cultures, selon ce texte de 2015 : https://www.facebook.com/notes/kent-beck/functional-tdd-a-clash-of-cultures/472392329460303
• Vivre cent jours en appliquant le TDD, regard de Jason McCreary en 2015 : http://jason.pureconcepts.net/2015/08/100-days-practicing-tdd/

Critiques :

• Quelques mythes associés au TDD, répertoriés en 2013 : http://schneide.wordpress.com/2013/03/11/tdd-myths-the-problems/
• Selon Justin Searls en 2014, TDD ne s'adresse pas aux débutant(e)s : http://blog.testdouble.com/posts/2014-01-25-the-failures-of-intro-to-tdd.html
• Certains critiquent la dévotion à une telle pratique, comme par exemple Dan North en 2012 : http://dannorth.net/the-art-of-misdirection/
• En 2014, Kent Beck (oui, le père spirituel du TDD) déclare morte cette technique : https://www.facebook.com/notes/kent-beck/rip-tdd/750840194948847
  • Critique du TDD, par David Heinemeier Hansson en 2014 : http://david.heinemeierhansson.com/2014/test-induced-design-damage.html
  • Position de Gary Bernhardt quant à la polémique entourant TDD, en 2014 : https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric
  • Position de Gary House quant à la polémique entourant TDD, en 2014 : http://www.bitnative.com/2014/05/01/the-tdd-divide/
  • En 2014, David Heinemeier Hansson clame « TDD est mort, longue vie aux tests! » : http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
  • Ce qui manque à ce débat, selon Marco Behler en 2014 : http://blog.marcobehler.com/whats-desparately-missing-from-the-tddtesting-debate/
  • TDD est-il mort? L'opinion de Robert C. Martin en 2014 : http://blog.cleancoder.com/uncle-bob/2014/06/17/IsTddDeadFinalThoughts.html
• Quand les tests font plus de mal que de bien à unb design, par Robert C. Martin en 2014 : http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html
• Dans ce texte de 2014, Craig Weber explique pourquoi il a adopté cette pratique : http://www.weberc2.com/posts/2014/12/22/test-driven-development.txt
• Intéressante corrélation entre l'effet du jeu sur ceux qui en éprouvent une dépendance, et l'effet du TDD sur les programmeurs dans « la zone », par Jef Claes en 2014 : http://www.jefclaes.be/2014/12/tdd-as-crack-cocaine-of-software.html
• Selon Sandro Mancuso en 2015, appliquer TDD ne mène pas nécessairement à un meilleur design : http://codurance.com/2015/05/12/does-tdd-lead-to-good-design/
• En 2015, Manuel Lemos donne sept raisons pour lesquelles TDD est un échec selon lui : http://www.phpclasses.org/blog/post/237-7-Reasons-Why-TDD-Failed-to-become-Mainstream.html

Tests unitaires (Unit Tests)

• Qu'est-ce qu'un test unitaire?
  • Un Wiki l'explique : http://en.wikipedia.org/wiki/Unit_testing
  • Une introduction à cette pratique, proposée en 2013 par Kosta Hristov : http://www.developingthefuture.net/writing-high-quality-unit-tests-tutorial/
  • Introduction aux tests unitaires, texte de 2013 : http://freepythontips.wordpress.com/2013/11/15/introduction-to-unittest/
• Selon Phil Calçado, en 2011, l'unité de test de code est l'unité d'entretien de code : http://fragmental.tw/2011/06/15/the.html
• Automatiser les tests unitaires de classes en C++ :
  • un texte de votre humble serviteur : Auto-Tests-Unitaires.html
  • une proposition du Code Project : http://www.codeproject.com/KB/applications/shortcut.aspx
  • http://blogs.msdn.com/b/jsocha/archive/2010/11/19/writing-unit-tests-in-visual-studio-for-native-c.aspx
  • démarche proposée par Martin Moene en 2014 : http://martin-moene.blogspot.nl/2014/11/block-scoped-fixtures-in-c.html
• Implanter les tests unitaires par programmation orientée aspect : http://www.ibm.com/developerworks/java/library/j-aopwork11/index.html?ca=dgr-lnxw01AOPtesting
• Tests unitaires avec J2EE, selon Adam Bien en 2011 : http://www.oracle.com/technetwork/articles/java/unittesting-455385.html
• Un texte de Matt Spitz en 2012, qui se proclame lui-même évangéliste (ou plutôt, pour être honnête, ardent défenseur) des tests unitaires : http://mattspitz.me/post/16397940902/i-scream-you-scream-we-all-scream-for-unit-tests
• Les tests unitaires pour programmeurs paresseux, texte de Swizec Teller en 2012 : http://swizec.com/blog/unit-testing-is-for-lazy-people/swizec/3752
• Des tests unitaires en R, texte de Gary Sieling en 2012 : http://garysieling.com/blog/unit-testing-with-r
• En 2012, Andrew Hunter soulève une question, à savoir « abusons-nous des tests unitaires? » : http://www.simple-talk.com/dotnet/.net-framework/are-unit-tests-overused/
• Il ne faut pas confondre test unitaire et validation. Texte de 2013 : http://crazyagility.wordpress.com/2013/06/10/unit-tests-are-not-for-validation/
• Selon Michael Nygard en 2013, mieux vaut automatiser (a) la validation de contrats, (b) les tests de propriétés, (c) l'injection de pannes et (d) la simulation que de réaliser des tests unitaires : http://thinkrelevance.com/blog/2013/11/26/better-than-unit-tests
• Tests unitaires pour systèmes embarqués, texte de 2014 par Stephen Friederichs : http://www.embeddedrelated.com/showarticle/558.php
• Définir plus clairement le concept, texte de Martin Fowler en 2014 : http://martinfowler.com/bliki/UnitTest.html
• En 2014, Scott Smith parle de l'unité dans les tests unitaires : http://coding.moris.org/archives/2014/04/28/the-unit-in-unit-testing/
• Texte de Martin Fowler en 2014 sur l'impact positif des tests unitaires dans la prévention de bogues graves : http://martinfowler.com/articles/testing-culture.html
• Douze trucs pour réussir ses tests unitaires, par Alex Iskold en 2008 : http://readwrite.com/2008/08/13/12_unit_testing_tips_for_software_engineers
• Douze mythes quant aux tests unitaires, par Eli Lopian en 2015 : http://www.dotnetcurry.com/showarticle.aspx?ID=1078
• En 2014, Jeremy Wright discute de Property Testing, une approche à l'implémentation de tests unitaires sur la base de propriétés manifestes qu'un objet doit exhiber : http://www.codestrokes.com/2014/09/property-testing-in-c/
• Texte d'Arne Mertz en 2015 mettant l'accent sur l'importance de faire en sorte qu'un test unitaire se complète rapidement : http://arne-mertz.de/2015/03/one-hour-of-unittests/
• Les hauts et les bas des tests unitaires, réflexion de Tomasz Wegrzanowski en 2015 : http://t-a-w.blogspot.ca/2015/04/the-rise-and-fall-of-unit-testing.html
• Réflexions d'Arne Mertz en 2015 sur les tests unitaires :
  • à quoi servent-ils? http://arne-mertz.de/2015/05/purposes-of-unit-tests/
  • quelles sont leurs principales caractéristiques? http://arne-mertz.de/2015/05/properties-of-unit-tests/
  • un test unitaire devrait être découplé ce que qui est testé, et ne devrait pas être un ami (friend en C++) de ce qu'il tests : http://arne-mertz.de/2015/08/unit-tests-are-not-friends/
• En 2015, Johu Snellman décrit une approche pour réaliser des tests unitaires sur une pile TCP : http://www.snellman.net/blog/archive/2015-07-09-unit-testing-a-tcp-stack/
• Les principales caractéristiques d'un bon test unitaire, de l'avis d'Eric Elliott en 2015 : https://medium.com/javascript-scene/what-every-unit-test-needs-f6cd34d9836d
• Réaliser des tests unitaires à partir d'assertions dynamiques, texte de 2018 par Matt Chernosky : http://www.electronvector.com/blog/unit-testing-with-asserts

Outils :

• Utiliser Boost.Test :
  • texte de Terry Mahaffey en 2012 : http://terrymahaffey.com/post/19545904600/using-boost-test
• testdriven.net, un outil pour réaliser des tests unitaires :
  • http://testdriven.net/
  • http://blogs.msdn.com/b/danielfe/archive/2007/05/31/visual-studio-express-and-testdriven-net.aspx
  • http://weblogs.asp.net/nunitaddin/default.aspx
  • http://weblogs.asp.net/nunitaddin/archive/2007/05/30/microsoft-vs-testdriven-net-express.aspx
• CuTest, pour réaliser des tests unitaires en C : http://cutest.sourceforge.net/
• L'outil JUnit sur Eclipse :
  • http://www.junit.org/
  • selon la perspective d'un programmeur .NET, un texte de 2010 : http://www.barebonescoder.com/2010/07/unit-testing-with-junit-eclipse-from-a-net-perspective/
  • un guide : http://howtodoinjava.com/2012/11/05/unit-testing-best-practices-junit-reference-guide/
• L'outil NUnit :
  • http://www.nunit.org/index.php
  • comparer MSTest et NUnit, un texte de 2011 : http://www.barebonescoder.com/2011/03/mstest-vs-nunit-with-visual-studio-2010-tdd-redux/
• L'outil CppTest : http://cpptest.sourceforge.net/
• L'outil TestNG : http://testng.org/doc/index.html
• L'outil Minitest, pour Newspeak, par Gilad Bracha : http://gbracha.blogspot.com/2011/02/ministry-of-nesting-testing.html
• L'outil NSpec, pour la plateforme .NET : http://www.nspec.org/
• L'outil Catch, pour réaliser des tests avec C++, décrit en 2014 : http://blog.coldflake.com/posts/Testing-C++-with-a-new-Catch/

Critiques :

• Trop faire de tests unitaires n'est peut-être pas l'idéal, selon Cédric Beust en 2011 : http://drdobbs.com/architecture-and-design/231600404
• C'est acceptable de ne pas écrire des tests unitaires, un texte de 2009 : http://blogs.msdn.com/b/cashto/archive/2009/03/31/it-s-ok-not-to-write-unit-tests.aspx
• Le vilain test unitaire (celui dont on abuse, en fait), un texte d'Alberto Gutierrez en 2012 : http://www.makinggoodsoftware.com/2012/01/27/the-evil-unit-test/
• En 2014, James O Coplien dit être d'avis que les tests unitaires sont une perte de temps : http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf
  • pour un suivi, voir ce texte de Henrik Warne en 2014 : http://henrikwarne.com/2014/09/04/a-response-to-why-most-unit-testing-is-waste/
• En 2014, l'auteur de ce texte exprime son déplaisir face aux tests unitaires : http://blogs.perl.org/users/ovid/2014/06/sick-of-being-mocked-by-unit-tests.html

Tests de régression

• Qu'est-ce qu'un test de régression? Un Wiki l'explique : http://en.wikipedia.org/wiki/Regression_testing
• Le marais des tests de régression, un opinion de Hans-Eric Grönlund en 2011 : http://www.hans-eric.com/2011/01/17/the-swamp-of-regression-testing/

Tests A/B

• Qu'est-ce qu'un test A/B? Un Wiki l'explique : http://en.wikipedia.org/wiki/A/B_testing
• Une opinion d'Uday Gajendar, en 2011, à l'effet que les designers n'aiment pas les tests A/B (et, en réfléchissant à leur point de vue, on ne peut que comprendre) : http://www.ghostinthepixel.com/?p=549
• Selon Steve Hanov, en 2012, on pourrait faire bien mieux : http://stevehanov.ca/blog/index.php?id=132
• Améliorer les tests A/B, selon Jessica Thomas en 2014 : http://blog.sendwithus.com/a-better-approach-to-ab-test-analysis/
• Texte d'Evan Miller en 2014 expliquant comment ne pas tenir un test A/B : http://www.evanmiller.org/how-not-to-run-an-ab-test.html
• Réflexion de John D. Cook en 2015 sur la relation entre la valeur d'un test A/B et le trafic sur un site Web : https://www.johndcook.com/blog/2015/10/28/ab-testing/
• En 2016, Maria Gullickson propose quelques pistes pour assurer la valeur d'un test A/B : https://engineering.snagajob.com/a-b-test-gotchas-3643b3701734
• Texte de Brendand McMenamin en 2017 portant sur les pièges associés à la réalisation de tests A/B sur des réseaux sociaux : https://tech.okcupid.com/the-pitfalls-of-a-b-testing-in-social-networks/

Cas vécus :

• En 2017, Raymond Chen explique un choix parfois critiqué de comportement sur Microsoft Windows à partir des résultats d'un test A/B : https://devblogs.microsoft.com/oldnewthing/?p=96205

Critiques :

• Texte de Martin Goodson, qui laisse entendre que la plupart des résultats « gagnants » obtenus lors de tests A/B soient discutables : http://www.qubit.com/sites/default/files/pdf/mostwinningabtestresultsareillusory_0.pdf
• Ce texte critique de 2016 par Justin Megahan suggère que la plupart des tests A/B donnent des résultats bidons : https://mixpanel.com/blog/2016/02/04/why-most-a-b-tests-give-you-bullshit-results/

Sujets connexes :

• Des tests A/A, texte de Julia Evans en 2015 : http://jvns.ca/blog/2015/02/06/a-a-testing/

Tests de mutation

• En 2015, l'équipe d'IMVU, avec les mots de Llorens Marti Garcia, explique comment elle réalise des « tests de mutation », changeant localement des éléments clés du code source pour délimiter l'impact de ces changements : http://engineering.imvu.com/2015/02/22/mutation-testing/

Cas d'espèces

• Comment la base de données SQLite est testée : http://www.sqlite.org/testing.html
• Tester du code JavaScript :
  • écrire du code facile à tester, un texte de Shane Tomlinson en 2013 : https://shanetomlinson.com/2013/testing-javascript-frontend-part-1-anti-patterns-and-fixes/
  • du TDD avec JavaScript, par James Shore : http://www.letscodejavascript.com/
• Tester un générateur de nombres pseudo-aléatoires, un chapitre du livre Beautiful Testing par John D. Cook : http://www.johndcook.com/Beautiful_Testing_ch10.pdf
• En 2015, article de l'équipe d'ingénierie d'IMVU qui explique comment leurs tests ont mené à la découverte d'un bogue dans la strate SSL de Microsoft Windows : http://engineering.imvu.com/2015/01/27/the-case-of-the-page-cant-be-displayed-intermittent-selenium-test/