C++20 est toujours compatible avec C++98, tu ne réécris pas pour le plaisir de réécrire. Tu migres lentement la code-base pièce par pièce en utilisant les nouvelles fonctionnalités du C++ moderne quand requises.
C'est ce que j'appelle une réécriture. J'ai pas dis que c'était fais d'un bloc. Je dis que tu es passé partout pour passer ton code de C++ non normalisé à C++98 puis de C++98 à C++11. Tu as eu un travail spécifique de montée de version de ton code. Et c'est pas une critique c'est normal. C'est juste que quand on vient me dire qu'une base de code est maintenu depuis 30 ans, le maintiens d'une base de code ça consiste à la faire évoluer qu'il a fallu prendre en compte au moins C++98 et C++11 etc.
Boost.UnitTest ou Catch2 permet d'écrire des tests en 5 lignes de code.
Je n'ai même pas besoin d'aller voir ce qu'ils font exactement pour savoir qu'on ne parle pas de la même chose. Avoir un runtime de test c'est un premier point, mais il y a un paquet d'autres choses qui peuvent aider :
une bibliothèque de mock, ne pas dépendre d'une base de données ou d'un brocker de message pour exécuter tes tests est très utile
une bibliothèque de génération de données, ça permet de construire bien plus rapidement les inputs de tes tests. nbuilder du monde .Net ou faker.js sont pas mal pour ça
avoir une bibliothèque d'assertions ce qui permet de se rapprocher de test de propriétés (de tester des nombres à virgules flottantes, du temps, des structures complexes,...).
Après le runtime de tests peut aussi servir à créer des tests suites et de faire des tests paramétrés, générer des rapports pour des outils comme sonarqube.
De ce que j'en vois Boost.UnitTest et Catch2 font des choses bien, mais ils sont loin de faire toutes ces choses.
Le duck typing n'apporte rien ici, le duck typing et le typage dynamique ont généralement l'effet inverse. Ils rendent nécessaires des batteries de testes larges et complexes pour gérer le large eventail d'input / possibilité que le duck typing autorise sur ton code et tes fonctions.
Le duck typing consiste a vérifier que la référence que l'on te donne possède les propriétés nécessaires à ce que tu en fais. C'est le typage dynamique qui rend la chose plus difficile. Mais c'est clairement une aide au mocking.
5 ans en arrière j'aurai dit oui. Aujoud'hui je dis non.
Oui ça aura mis du temps à arrivé, mais la situation s'est bien amélioré. Je l'ai découvert ici en discutant.
[^] # Re: Performance
Posté par barmic . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 3.
C'est ce que j'appelle une réécriture. J'ai pas dis que c'était fais d'un bloc. Je dis que tu es passé partout pour passer ton code de C++ non normalisé à C++98 puis de C++98 à C++11. Tu as eu un travail spécifique de montée de version de ton code. Et c'est pas une critique c'est normal. C'est juste que quand on vient me dire qu'une base de code est maintenu depuis 30 ans, le maintiens d'une base de code ça consiste à la faire évoluer qu'il a fallu prendre en compte au moins C++98 et C++11 etc.
Je n'ai même pas besoin d'aller voir ce qu'ils font exactement pour savoir qu'on ne parle pas de la même chose. Avoir un runtime de test c'est un premier point, mais il y a un paquet d'autres choses qui peuvent aider :
Après le runtime de tests peut aussi servir à créer des tests suites et de faire des tests paramétrés, générer des rapports pour des outils comme sonarqube.
De ce que j'en vois Boost.UnitTest et Catch2 font des choses bien, mais ils sont loin de faire toutes ces choses.
Le duck typing consiste a vérifier que la référence que l'on te donne possède les propriétés nécessaires à ce que tu en fais. C'est le typage dynamique qui rend la chose plus difficile. Mais c'est clairement une aide au mocking.
Oui ça aura mis du temps à arrivé, mais la situation s'est bien amélioré. Je l'ai découvert ici en discutant.