Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Programmation Test-Safe #37

Closed
adpi2 opened this issue Apr 27, 2019 · 1 comment
Closed

Programmation Test-Safe #37

adpi2 opened this issue Apr 27, 2019 · 1 comment
Labels
Misc Retex, Conf review, Methodologies, Tools and whatever doesn't fit in other labels
Milestone

Comments

@adpi2
Copy link

adpi2 commented Apr 27, 2019

Programmation Test-Safe

Le(s) speaker(s)

Piquerez Adrien, Développeur à Ippon Technologie

Abstract

La programmation test-safe est une méthode de programmation centrée sur les tests. C'est du TDD, mais natif, du TDD par design ! Plus concrétement c'est l'idée que les tests sont la source du programme, et que l'implémentation est le produit des tests. L'idée est belle, mais comment ça marche ? Ce talk est un début d'aventure, en live coding, vers une librairie de programmation test-safe. En scala, mais pas de panique, aucune notion de scala n'est requise pour comprendre.

Détails

Dans le monde Java, et dans beaucoup d'autres langages :

  • les tests dépendent de l'implémentation, car l'objet testé est construit par la classe de test.
  • les tests sont à l'écart du code de production : le code de production est dans src/main et les tests sont dans src/tests

La programmation test-safe inverse la dépendance entre la classe de test, qu'on appellera spécification, et l'implémentation qu'elle teste. Autrement dit, la spécification s'exprime sur l'interface, aussi appelé trait, et l'implémentation est un produit de la spécification.

Le programme est test-safe car l'implémentation valide les tests par définition. Le programme ne compilerait pas sinon.

Ainsi on change la façon de penser et de programmer le logiciel par les tests, comme avec TDD mais structurellement :

  • l'ajout d'une fonctionnalité se traduit par l'ajout d'une spécification (de tests)
  • un bug se corrige par l'ajout d'un test, pour préciser la spécification
  • si le besoin change on change la spécification

On peut combiner plusieurs spécifications d'un même trait. Par exemple spécification fonctionnelle et technique, ou pourquoi pas spécification de sécurité. On peut aussi combiner plusieurs traits en une même implémentation.

Au cours du talk je développerait l'idée de "test safety" en codant en live un petit programme, probléme algorithmique ou petit jeu.

Cette méthode de programmation s'inspire du paradigme déclaratif, car elle décrit d'abord le "quoi" par la spécification avant le "comment", l'implémentation. On peut déléguer au systéme la construction de l'implémentation par combinaison d'éléments atomiques qui lui sont fournis. C'est ainsi que sera ouvert le talk, par d'autres pistes de réfléxions: génération automatique de code ? language de programmation test-safe ?

Informations diverses

  • Niveau de difficulté : intermédiaire
  • Durée : 1h
  • Format : les slides + live-coding
  • Dispo ou indispo : dès que possible
@arnaudbos arnaudbos added the Misc Retex, Conf review, Methodologies, Tools and whatever doesn't fit in other labels label Apr 27, 2019
@jzanon
Copy link

jzanon commented Jan 9, 2020

Salut Adrien,
On cherche un speaker pour la 2ème partie de soirée du jeudi 16 janvier, est-ce que tu serais dispo ?

@arnaudbos arnaudbos added this to the Janvier 2020 milestone Jan 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Misc Retex, Conf review, Methodologies, Tools and whatever doesn't fit in other labels
Projects
None yet
Development

No branches or pull requests

3 participants