Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Mais pourquoi faire du TDD ?

Mais pourquoi faire du TDD ?

On entend souvent parler du TDD (Test Driven Development) dans les livres ou les articles de blog. Mais au fait : c'est quoi le TDD ? Comment ça se pratique ? Et pourquoi au juste ? A travers cette présentation, je vous propose donc de découvrir ce concept qui trouve ses origines dans l'eXtreme Programming, d'aborder ses objectifs et limitations. Car oui, le TDD n'est pas réservé qu'aux hipsters !

[Conférence donnée lors de la Pytong 2015]

Alexandre Figura

September 26, 2015
Tweet

More Decks by Alexandre Figura

Other Decks in Programming

Transcript

  1. Qui suis-je ? • Ancien sysadmin. • Aujourd'hui développeur web

    Python. • Travaille sur des projets d'autopartage (comme Bluely), chez Polyconseil.
  2. Au fait, c'est quoi le TDD ? • Test-Driven Developement

    (ou développement piloté par les tests). • Le principe est simple : “Tu écris un test, et ensuite tu codes.” • Le TDD est un moyen comme un autre d'avoir des tests automatisés.
  3. Les origines du TDD • Vient du monde agile. •

    Plus particulièrement de l'eXtreme Programming. • XP regroupe de nombreuses pratiques, dont : – Pair Programming, – Continuous Integration. • XP est censé vous permettre d'écrire du code plus robuste et simple à maintenir.
  4. Un peu de contexte • Bob adore faire de bons

    plats. • Il aimerait partager ses recettes sur un site web. • Nous allons l'aider en utilisant Flask et Pytest. Le TDD sera notre guide...
  5. Etape n°1 Ecrire un test fonctionnel* *Traditionnellement, le TDD se

    limite aux tests unitaires. Mais d'autres pratiques similaires ont vu le jour (comme l'Acceptance Test-Driven Development).
  6. Notre test fonctionnel def test_write_a_recipe(): # Bob checks out the

    homepage of his website. browser = selenium.webdriver.Firefox() browser.get('http://localhost:5000/') # He has just invented a new recipe and wants to write it down. new_recipe = 'Côte de boeuf hibernée au coulis de framboise.' textarea = browser.find_element_by_id('new_recipe') textarea.send_keys(new_recipe) textarea.send_keys(selenium.webdriver.common.keys.Keys.ENTER) # His new recipe is now shared with the rest of the world. recipes = [r.text for r in browser.find_elements_by_class_name('recipe')] assert recipes == [new_recipe]
  7. Lançons le test une première fois > assert 'Bob Recipes'

    in browser.title E assert 'Bob Recipes' in 'Problem loading page' Aucun serveur web ne tourne !
  8. On relance le test... > assert 'Bob Recipes' in browser.title

    E assert 'Bob Recipes' in '404 Not Found' Il faut créer une vue pour notre page d'accueil.
  9. Notre test unitaire def test_get_homepage(client): response = client.get('http://localhost:5000/') assert response.status_code

    == 200 > response = client.get('http://localhost:5000/') E webtest.app.AppError: Bad response: 404 NOT FOUND (not 200 OK or 3xx redirect for http://localhost:5000/) Et son résultat
  10. Vue de la page d'accueil @app.route('/') def homepage(): return '<head><title>Bob

    Recipes</title></head>' ============== test session starts ============== tests/test_views.py . =========== 1 passed in 0.01 seconds =========== On relance le test unitaire...
  11. On relance le test fonctionnel... > textarea = browser.find_element_by_id('new_recipe') E

    selenium.common.exceptions.NoSuchElementException: Message: Unable to locate element: {"method":"id","selector":"new_recipe"} Une nouvelle erreur survient !
  12. Le jeu des erreurs • Nous pourrions continuer longtemps à

    corriger des erreurs pour comprendre comment faire du TDD. • Mais quelqu'un s'en est déjà chargé...
  13. Les différentes étapes du TDD 1) Ecrire un test. 2)

    Vérifier qu'il échoue. 3) Ecrire du code. 4) Vérifier que le test passe. 5) Procéder à du refactoring. RED GREEN REFACTOR
  14. Les bénéfices du TDD • Force à se concentrer d'abord

    sur le comportement du code testé plutôt que son implémentation. • Incite à écrire du code simple. • Participe à faire du design incrémental. • Permet de délivrer plus rapidement un Minimum Viable Product. • Assiste dans l'apprentissage de nouveaux frameworks.
  15. Les limites du TDD • Le TDD n'est pas silver

    bullet. • Parfois difficile à appliquer sur une base de code existante. • Inutile lorsque l'on est pas certain du comportement attendu du code testé.
  16. Les défauts du TDD • Peut-rendre fou : TDD is

    dead. Long live testing. David Heinemeierhansson • Heureusement, une cure existe : Is TDD Dead? Martin Fowler • A retenir : il ne faut pas se focaliser sur l'écriture de tests isolés à tout prix.