Je ne sais pas pour Gnome (bien que j'aurai plutot tendance a etre d'accord), mais je peux t'assurer que KDE est principalement developpe en Europe.
Tous les ans, KDE organise une conference (aKademy). Le sujet a ete debatu plusieurs fois dans les listes de KDE et il est tres difficile d'organiser cette conference hors de l'europe, parce que tres peu de developpeurs pouraient y assister.
Le fait d'organiser une conference en Europe pose des problemes aux 4 ou 5 developpeurs americains, mais guere plus.
Pour etre plus precis, KDE est principalement developpe en Allemagne et dans les pays nordiques. C'est pas un choix, c'est une constatation. Je pense qu'il y a des effets de reseaux locaux qui fait que plusieurs developpeurs d'un meme pays vont souvent se regrouper.
Ca n'empeche pas chacun des projets d'accueillir les developpeurs du monde entier.
KDE assiste a tres peu de conferences aux US, en revanche, il est bien present a toutes les conferences allemandes, neerlandaises, autrichiennes, francaises, belges, ...
Un brevet est rendu public au bout de 2 ans (ou bien 1 an, je ne sais plus). En attendant, tu peux violer un brevet sans le savoir. Mais on ne t'en veux pas dans ce cas-la, il faut juste que tu payes les royalties une fois que le brevet est publie.
Alors comment breveter un truc publie ? Normalement, c'est impossible. Mais tu peux trouver des moyens. Genre, le format decrit un mecanisme pour faire X et toi, tu brevettes une implementation de X. Ou bien le format decrit une un mecanisme pour faire Y, sachant que dans 90% des cas, ce sera utilse pour faire Z, mais que pour laisser plus de possibilites d'extensions futures, on ne decrit que Y. Toi, tu brevettes Z.
Bref, il y a pas mal de moyen de contourner la forme, meme si dans le fond, on reste toujours autour du "je brevette une idee ou une implementation logicielle bidon".
Pour ton employeur, pense a ce qui va se passer une semaine plus tard:
- quoi, ca ne marche toujours pas
- ben c'est que il y a quelques bugs compliques que j'ai du mal a regler
- mais je comprends pas, au bout d'un jour, ca marchait deja
- oui, mais c'etait pas fini, il y avait encore du travail plus difficile a faire
Alors que avec les tests unitaires, le depart est plus difficile, mais le finish est plus facile. Surotut quand au bout d'une semaine, il t'explique que tu n'as pas compris sa demande et qu'il faut tout changer. Avec tes tests unitaires, tu es zen.
Tu vois, meme ton patron serait content.
Sinon, pour mieux faire passer la pilule:
- il faut viser en priorite les fonctionnalites les plus utiles
- tu codes et tu testes en meme temps. Donc au bout d'une journee, tu as quand meme une partie du code qui est ecrite.
Il suffit de s'interfacer sur kio de KDE pour faire marcher ca. Donc pour kyzis, ce sera pas trop complique a rajouter. Il faut juste faire attention, puisque dans libyzis, qui est responsable de l'ouverture et l'enregistrement du fichier, on utilise pas kio. Uh uh, va falloir trouver un moyen pour resoudre ce probleme.
Donc finalement, a la question "qui de l'OS ou du compilateur est la en premier ?", tu reponds le compilateur parce que le processeur est un compilateur.
En fait, je suis d'accord avec toi que tout repose sur le langage du processeur mais je verrai plutot celui-ci comme un systeme d'exploitation. Le processeur lit des donnees (un programme), deplace des donnes de la RAM vers les registres, des registres vers les bus materiels, etc, etc. Tout ca ressemble a un OS.
En revanche, pour ce faire, il a fallu ecrire un interpreteur pour le langage machine, qui tourne dans le processeur. Ca ressemble encore a un OS.
En fait, meme si a priori, le compilateur parait indispensable, c'est beaucoup moins util qu'un OS. Le compilateur ne fait que fabriquer des programmes qui pourront s'executer. Son travail peut etre remplace par un cerveau humain. En 85, je faisais de l'assembleur en ecrivant mon code sur une feille de papier, puis en cherchant dans le bouquin de reference du MSX (assebembleur Z80) les valeurs hexadecimales des instructions, puis en les codant sous forme de chaine de caractere dans un programme en basic et en faisant un appel sur l'adresse des chaines de caractere. Dans ce cas, je me passais d'un compilateur, c'est mon cerveau qui faisait le travail. Mais tout ca n'aurait pas pu avoir lieu si je n'avais pas eu un OS, en l'occurence Microsoft MSX Basic.
Donc pour moi, la reponse est clairement que l'OS etait la avant le compilateur.
Le monsieur t'explique qu'il y a un probleme de vocabulaire. Ce que tu appelles test unitaire est en fait un test fonctionnel. Les tests unitaires et les tests fonctionnels sont deux choses tres bien, mais distinctes.
Le signification de test unitaire est acceptee par beaucoup de monde et signifie "tester independamment des morceaux de code". Le but est de mettre en evidence des problemes dans un morceau precis de code de facon a faire de la non-regression. Cette definition est supportee d'une part par les livres traitant d'extrem programming, d'autre part par la communaute et les outils de test unitaires.
Les tests fonctionnels ont un autre role: validation de l'integration de toutes les briques ensemble, stress de l'application par l'envoi de requetes en serie, reproduction du comportement d'un utilisateur.
Typiquement, comme te le dis le monsieur plus haut, creerClient va juste generer une requete SQL fictive et validera que la requete est ce qu'elle doit etre. Idem pour creerDevis. La conclusion logique, c'est que lancer l'un apres l'autre ne stresse pas du tout l'application car ce sont des tests _unitaires_
Maintenant, tu peux mettre en place des tests fonctionnels, en t'appuyant aussi sur Junit et les executer via un scenario. C'est une bonne idee et je fais ca aussi dans mes projets. Dans ce cas, ton test creera effectivement une vraie base de donnee et reproduira le comportement d'un utilisateur.
C'est le fait que JUnit puisse etre utilise dans deux contextes differents (tests unitaires, tests fonctionnels) qui seme la confusion ici.
En continuant a appeler ton projet JUnitScenario, tu risques de ne pas du tout faire comprendre l'utilite de ton soft (donc tu peux oublier les contributeurs):
- les gens qui ne connaissent rien au test unitaire ne seront pas interesses
- les gens qui connaissent les tests unitaires comme moi trouveront ton bidule inutile.
Je te conseille donc pour le bien de ton projet de faire bien comprendre le message. Qqch comme:
"JunitScenario builds an automation framework on top of JUnit to perform functional tests and stressing tests".
Une fois que ce point la est eclairci, ton projet devient interessant.
Mais si tu veux, tu peux continuer a appeler test unitaire un test fonctionnel. Tu peux aussi appeler le soleil "Lune". Mais ca reste le soleil et personne ne te comprendra.
En tout cas, ca apporte de l'eau a mon moulin personnel : c'est finalement beaucoup plus dur de faire une bonne applet javacard qu'un bon bout de code en C des familles.
DCOP s'appuie sur lib-je-sais-plus-quoi qui est en fait une lib de X pour etablir des communications. Celle-ci s'appuie (si je me souviens bien) sur les atomes X pour faire certains exhanges.
Il y a d'autres parties dans KDE qui dependent des atomes X mais je ne suis pas assez pointu pour te dire lesquelles. Il me semble que la gestion de la session et la creation des repertoires temporaires utilisent partiellement des petits mecanismes de X
Ce que vous faites, j'appelle ca un test fonctionnel. Je reste sceptique dans la mesure ou un test unitaire reste unitaire, c'est a dire dedie a une fonctionnalite precise.
La somme des tests unitaires ne constitue pas un test fonctionnel. Il faut mettre son grain de sel (sa connaissance du fonctionnement du bazar) dedans. Dans mon experience, on s'appuie sur les mecanismes mis en place lors des tests unitaires, mais on ne re-utilise pas les tests unitaires tel quel.
C'est un peu comme la generation automatique de test unitaire a partir des headers. C'est genial sauf que 50 tests unitaires auto-generes ne peuvent remplacer des tests ecrits par le developpeur, qui va tester la ou ca fait mal.
Ce que tu me decris me semble plus facile a mettre en place avec un vrai test, fait non pas d'assemblage de tests unitaires, mais de reproduction du comportement d'un utilisateur.
Il y a Qt Embedded aussi qui marche sans serveur X. On trouve aussi konqueror embedded qui se passe tres bien de X. Si jamais KDE passe a dbus, on pourra aussi se passer enornment de X.
En tant que developpeur Qt chevronne, je te le recommande chaudement de te mettre a Qt. Perso, j'ai appris en lisant le tutorial de la documentation, que j'ai trouve tres bien fait.
Sinon, il existe un forum en francais http://prog.qt.free.fr/portal.php(...) et un certain nombre d'autres en anglais (qt-forum.org) pour trouver de l'aide. Il y a aussi des bouquins mais je ne crois pas qu'il y aie une version recente en francais.
Pour ce qui est de la transition MFC -> Qt, le site que tu donnes propose un outil qui te permettra de recuperer les parties graphiques d'une appli MFC (dialogue, ....) mais ne transformera pas le code. Cela dit, c'est beaucoup plus simple et plus propre de programmer un MFC qu'en Qt, donc tu ne devrais pas avoir de probleme.
Le site de Trolltech propose aussi de nombreux trucs pour passer de MFC a Qt.
Je ne suis pas d'accord avec toi et je trouve ton raisonnement tordu.
Avoir une doc decrivant un format, c'est la base de l'interoperabilite.
Avoir les sources, ca rend possible une demarche tres couteuse et sujette a erreur vis a vis de l'interoperatbilite. Je dois lire 10 000 lignes de code pour savoir que le bit X du byte Y correspond a la fonctionnalite Z ? Et que se passe-t-il si il y a une erreur d'implementation ? Comment tu montes tes tests de compabilite ?
Le garant d'une interoperabilite, c'est une documentation decrivant un format.
L'exemple emblematique etant OpenOffice, qui bien qu'ayant de tres bon filtres pour les documents word, est absolument inutilisable en terme d'interoperabilite sur ce point. Le code n'est tout simplement pas re-utilisable tel quel et imbitable.
J'ai ecrit au journaliste pour lui dire qu'il avait ecrit plus de conneries que de phrases dans son article.
J'ai ete supris de recevoir un coup de fil: il s'est renseigne et va publier un correctif demain, et il me demandait quelques conseils. Finalement, ca fait de la pub a KDE.
> Je vois un truc "marrant". Les "fans" des tests unitaires, qui semblent nombreux, font rarement du logiciel
> libre sinon il y aurait plus de tests unitaires dans le logiciel libre.
Affirmation gratuite et mechante. Va voir sur ma page web, je fais du logiciel libre. Meme si ce n'est pas la prochaine killer app, je suis content et fier de ce que je fais. Et yzis a le potentiel pour etre la killer vim app.
L'engouement pour les tests unitaire est recent. Perso, j'ai decouvert ca il y a 3 ans avec XP. Je pense que c'est un peu similaire pour les autres ici. Donc je n'ai integre la notion dans mes projets libres que depuis 3 ans.
Mais depuis que je m'interesse au sujet, il y a plus de test unitaires dans le monde du logiciel libre. J'ai fait un qtunit (pas forcement mon meilleur projet), une suite de test unitaires pour lua (c'est deja mieux).
J'ai fait tous les tests unitaires et leur conception pour l'OS open source pour carte a puce jayacard (jayacard.sf.net).
Yzis beneficies d'une suite de test en C++ et d'une suite de test en lua, devines de qui elle vient ? C'est d'ailleurs une des raisons pour lesquelles il sera un meilleur editeur que vim a terme.
> Puis les tests unitaires quand t'as 300 paramètres d'exécutions et
> tu dépends d'un automate qui t'envois 200 autres paramètres,etc
Je doute que tu arrives a gerer tes 300 parametres et tes 200 autres avec une seule fonction. Tu as forcement un decoupage du travail qui t'oblige a separer les taches. Une fois que tu as isole les taches, tu peux les tester individuellement.
> Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
En general c'est mieux d'avoir un simulateur sous la main, pour reproduire les cas pourris. J'en ai rarement vu dans le libre malheureusement.
> Dans certain cas tu n'as pas le choix. Une équipe développe l'applis, une autre bosse sur un automate qui va utiliser des
> appareils à plusieurs millions d'euro qui sera disponible que lorsque les développements sont terminés.
Parce que ca vaut plusieurs millions d'euro, tu crois qu'on ne peut pas faire de test ? Ou bien que je vais me dire "la vache, si ca vaut aussi cher, vaut mieux ne pas tester" ? Ton appareil, il a des entrees/sorties qui sont specifiees. Ben tu les utilises pour tes tests.
Tout ce qui a une api peut avoir un test.
> Mais je ne me vois pas demander au boss d'avoir 6 mois de plus
> pour faire des tests unitaires exautifs sans que ça apporte un réel intérêt.
Affabulation. Faire des tests unitaire te fait gagner du temps. Pas le jour ou tu les ecris, mais 6 mois plus tard, quand tu dois modifier le code que tu as ecrit. Tu es bien content de ne pas faire un audit complet de ton code pour verifier que le bug X n'a pas pete ton produit. Tu fais retourner ta suite de test, et hop, tu es tranquil. Les endroits ou ton produit est pete sont clairement isole.
Les tests unitaires, c'est une machine a gagner du temps. Je suis d'accord que c'est contre-intuitif comme idee, mais c'est vraiment le cas dans la pratique.
> Il faut alors que les éléments critiques soient simples.
C'est en effet la caracteristique d'une conception robuste.
> Ainsi tu peux "blinder" les tests unitaires et faire des tests exautifs sur les éléments critiques.
Ah, tu vois qu'on se comprend finalement.
> "Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Je ne suis pas d'accord. Pour tout projet de plus d'une heure, les tests unitaires te feront gagner du temps. Pour un projet typique, on code 80% du projet en 20% du temps. Les 20% restants sont les plus durs: bugs d'integration, ajustement de la conception, ...
Avec des tests unitaires, t'as plutot une progression lineaire de facteur 1: 20% du temps, 20% du projet. 50% du temps, 50% du projet. Evidemment, vous ne regardez que les 20 premiers % en disant "putain, je pourrai deja en etre a 80% et je n'en suis qu'a 20%". Mais au final, les dernier % sont torches a vitesse grand V. Tu peux meme te permettre de faire des changements majeurs dans le projet dans la phase finale pour integrer la derniere idee du mec marketing, sans avoir peur de miner ton produit. Alors qu'en general, les devs ne veulent plus toucher a rien dans la phase finale, parce qu'ils ont eu trop de bugs d'integration.
> - Faire un (ou des) test unitaire complet pour gecko
Comme je l'ai deja dit, les developpeurs de gecko font deja leurs tests. Ils ont plein de bouts de code qu'ils utilisent pendant leur dev. Seulement des qu'ils estiment que ca marche, au lieu d'integrer ces bouts de code dans une suite de non-regression, ils jettent.
C'est la qu'on perd du temps. Des choses qui sont developpees mais pas integree au produit. C'est sur que rajouter les tests apres, c'est tres difficile et tres couteux.
> Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Beaucoup moins que pour corriger les bugs de non- regression, pour relire le code et se prendre la tete a essayer de comprendre pourquoi la foncttion X est comme ca sans avoir le test qui explique et qui valide son comportement.
Il est evident cependant que les tests evoluent avec le soft. Mais c'est une bonne chose.
> Une fois que tu as évaluer les ressources nécessaires interroges si un développeur de plus uniquement pour faire
> de l'audit de code n'est pas un meilleur investissement.
Moi je m'interroge en terme de certitude.
- un developpeur qui audite le code: "je pense que ca marche"
- un test unitaire qui valide le code: "je suis sur que ca marche".
Il n'y a pas photo, je prend la 2e option.
> Mais parfois un module développé n'est utilisé que bien des mois après. [...] Mais suppose que les formats d'entrés aient légèrement
> changé et que lors des tests (pas des tests unitaires) ça plante un module développé il y a quelque mois. Ces "bricoles" ça arrive.
Non ? Tu m'apprend quelque chose, je croyais que tout marchait tout seul et que les tests ne servait qu'a valider la perfection du code que ton cerveau surpuissant avait deja garanti de toute facon.
Mais bien sur que ca arrive ! Et bien tu fais evoluer tes tests, en meme temps que ton module. Un principe de codage fondamental de XP, c'est "on ne code qqch qu'une seule fois". Si ton format change, tu modifies la fonction de lecture du format et le test correspondant. Hop. Si ta representaiton interne doit changer aussi, ben pareil, tu modifies les deux. Une fois que tu as fait ca, tu verifies que tous les modules affectes indirectement par tes changements fonctionnent encore. Tu fais un audit rapide de ta couverture de test sur ces modules. Si elle est bonne, voila, tu t'es economise quelques jours de prise de tete d'audit de tous les modules qui utilisaient ton code.
> Ça arrive car les tests peuvent être erronés ou incomplet, car il y a eu un manque communication lors de l'évolution d'un module, etc.
Bien sur, ca arrive tous les jours. Mais les tests ne sont pas graves dans la pierre, ils evoluent en meme temps que ton programme te que tes specs.
> Toi t'es dans le rève ou il n'y a pas d'erreurs de conception,
Pas du tout. Je passe meme une grande partie de mon temps a corriger mes erreurs de conception en faisant evoluer mes tests. Le fait d'etre un mauvais concepteur ne me gene pas, car j'ai de bonnes suites de tests.
> il n'y a pas de manque de communication, le projet est parfaitement géré, les tests sont tous exautifs et parfait, les
> spécifications sont complètes et n'ont raté aucuns scénarios, etc.
Si c'etait ca, je n'aurai pas besoin d'ecrire des tests. Au contraire, les tests m'aident a gerer tous les problemes classiques d'un projet de facon beaucoup plus zen:
- spec qui evolue => je fais evoluer mes tests
- module non encore dispo => je fais des tests et un simulateur pour le remplacer
- bug a la con decouvert => je fais un test pour encadrer le bug et je cherche tous ses cousins possibles, puis je corrige
- probleme d 'integration dans un autre module, on ne sait pas d'ou vient le probleme => je montre mes suites de test a l'autre developpeur, qui est ensuite convaincu que le probleme vient de son cote
- procedure ISO a suivre pour la validation des specs => j'associe a chaque fonctionnalite un test et mon rapport de test devient ma doc de validation
- je trouve un module super difficile a developper et a tester => c'est un signe de mauvaise conception, je le decoupe jusqu'a pouvoir le tester facilement
- on me dit que a la convergence de trois conditions tres tres rares, le soft ne marche pas => je modifie mon simulateur (pratique de l'avoir developpe avant) pour inclure ces conditions tres tres rares.
etc etc.
Les tests unitaires, c'est vraiment une methodologie de developpement qui me permet d'etre super zen dans ce que je fais et de gerer tous les problemes quotidiens avec du recul.
> Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Mon cauchemard, c'est les developpeurs qui pensent que leur cerveau demesure ne pond que du code correct.
Perso, je suis modeste et pessimiste. Je pense que le code que j'ecris ne marche pas. Alors, je cherche des preuves.
> Mais je vais te montrer un cas "spécial" et qui va te montrer que je ne suis pas contre les tests unitaires lorsque ça a un sens.
De fait, si tu les as utilise et que tu as vu leur valeur, je ne comprends pas pourquoi tu me critiques de facon aussi acharnee.
> J'ai réalisé les procedures de tests exautives (car c'était possible et ça permettait aussi de faire le recette auprès du client).
Ca rejoint ce que je disais sur la valeur des tests. Ca sert plus qu'au developpeur.
> Retard : 15 jours.
Chapeau!
> Le client ne s'est jamais plaint d'un bug.
C'est la caracteristique d'un programme avec de bons tests unitaires. Tres peu de bugs.
> Tous les tests ont été réalisés à la *fin* car pour *ce* projet c'était une bonne méthode.
Je pense que tu as pris des risques sur ton projet, que tu mesurais de facon consciente. Il aurait pu t'arriver des problemes, genre le client reviens au bout de 4 mois : "donnez nous ce que vous avez fait , et on arrete le projet. Puisque ca fait 4 mois que vous avez commence, vous en etes a la moitie. On paiera que pour ce qui marche uniquement".
Mais je ne critique pas ta demarche. C'est bien que tu aies reussie a faire ce qui paraissait impossible.
> C'est dingue ça, les gens "gueules" car lorsqu'il récupérère le premier logiciel venu sur le net (gentiment contributé, gratuit, etc) il n'est pas à
> leur gout et il pense que ça leur donne le droit de critiquer le libre dans son ensemble.
Je fais du logiciel libre et j'accepte les critiques. Je ne comprends pas pourquoi il n'en irait pas de meme de mes pairs developpeur. Refuser la critique, c'est toujours une forme d'extremisme. Accepter la critique et dire "ta critique est infondee" ou "ta critique est fondee mais ca restera comme ca", c'est de l'ouverture d'esprit.
Un logiciel est un outil, quand l'outil est pourri, il est juste de le critiquer. Si tu vois le logiciel comme une oeuvre d'art qu'il ne faut jamais executer parce qu'il plante, libre a toi. Mais si tu vois le logiciel comme un outil, tu dois etre pret a accepter la notion de critique, independamment de la facon dont ce soft a ete developpe.
> Quand des dev cherchent une info, ils la cherchent dans les headers des lib la plupart du temps.
Je sais pas d'ou tu sors ca, je ne suis pas d'accord. Dans le cas des lib pourries et mal documentees, le developpeur est contraint de chercher dans les headers.
Dans les libs que j'utilise, les docs sont bien faites et je ne vais jamais chercher dans les headers:
- boost
- qt
- python
- lua
- KDE
> Et les devs d'apache, ne font pas deux fois la même erreur: ils sont attentifs
Et oui, mais l'equipe des developpeurs change. Les anciens s'en vont, ces nouveaus les remplacent. C'est encore plus vrai en entreprise. La suite de test garantit que le qualite demeure dans le projet et pas seulement dans l'individu qui l'a code.
> (donc la batterie de tests codée après coup ne servira à rien par la suite).
C'est pas vrai. A la prochaine attaque sur URL, le code gerant les URL sera encore change. Il se peut qu'a ce moment, un developpeur introduise par megarde une modif qui enleve la correction precedente. Ca n'arrivera peut-etre pas mais tu n'as aucune garanti. Avec ta suite de test, tu as une garantie.
[^] # Re: Enfin, bon...
Posté par Philippe F (site web personnel) . En réponse au journal Gnome un projet américain ?. Évalué à 8.
Tous les ans, KDE organise une conference (aKademy). Le sujet a ete debatu plusieurs fois dans les listes de KDE et il est tres difficile d'organiser cette conference hors de l'europe, parce que tres peu de developpeurs pouraient y assister.
Le fait d'organiser une conference en Europe pose des problemes aux 4 ou 5 developpeurs americains, mais guere plus.
Pour etre plus precis, KDE est principalement developpe en Allemagne et dans les pays nordiques. C'est pas un choix, c'est une constatation. Je pense qu'il y a des effets de reseaux locaux qui fait que plusieurs developpeurs d'un meme pays vont souvent se regrouper.
Ca n'empeche pas chacun des projets d'accueillir les developpeurs du monde entier.
KDE assiste a tres peu de conferences aux US, en revanche, il est bien present a toutes les conferences allemandes, neerlandaises, autrichiennes, francaises, belges, ...
[^] # Re: Euh ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche OASIS envisage d'accepter les brevets. Évalué à 3.
Alors comment breveter un truc publie ? Normalement, c'est impossible. Mais tu peux trouver des moyens. Genre, le format decrit un mecanisme pour faire X et toi, tu brevettes une implementation de X. Ou bien le format decrit une un mecanisme pour faire Y, sachant que dans 90% des cas, ce sera utilse pour faire Z, mais que pour laisser plus de possibilites d'extensions futures, on ne decrit que Y. Toi, tu brevettes Z.
Bref, il y a pas mal de moyen de contourner la forme, meme si dans le fond, on reste toujours autour du "je brevette une idee ou une implementation logicielle bidon".
[^] # Re: Microbes
Posté par Philippe F (site web personnel) . En réponse au journal Tests unitaires et faineantise. Évalué à 4.
- quoi, ca ne marche toujours pas
- ben c'est que il y a quelques bugs compliques que j'ai du mal a regler
- mais je comprends pas, au bout d'un jour, ca marchait deja
- oui, mais c'etait pas fini, il y avait encore du travail plus difficile a faire
Alors que avec les tests unitaires, le depart est plus difficile, mais le finish est plus facile. Surotut quand au bout d'une semaine, il t'explique que tu n'as pas compris sa demande et qu'il faut tout changer. Avec tes tests unitaires, tu es zen.
Tu vois, meme ton patron serait content.
Sinon, pour mieux faire passer la pilule:
- il faut viser en priorite les fonctionnalites les plus utiles
- tu codes et tu testes en meme temps. Donc au bout d'une journee, tu as quand meme une partie du code qui est ecrite.
[^] # Re: Rangement du frigo Howto
Posté par Philippe F (site web personnel) . En réponse au journal Tests unitaires et faineantise. Évalué à 4.
[^] # Re: assertions préconditions
Posté par Philippe F (site web personnel) . En réponse au journal Tests unitaires et faineantise. Évalué à 2.
Les tests unitaires te permettent de valider en permence que ton programme fait ce qu'il doit faire, correctement.
[^] # Re: tkinter
Posté par Philippe F (site web personnel) . En réponse au journal wxWidgets 2.5.4 disponible sur SF. Évalué à 3.
[^] # Re: arghhhh
Posté par Philippe F (site web personnel) . En réponse au journal Kde 3.4 et composite. Évalué à 2.
[^] # Re: sugestion
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis M3 est arrivé. Évalué à 2.
[^] # Re: Hmmm
Posté par Philippe F (site web personnel) . En réponse au journal L'oeuf ou la poule ?. Évalué à 2.
En fait, je suis d'accord avec toi que tout repose sur le langage du processeur mais je verrai plutot celui-ci comme un systeme d'exploitation. Le processeur lit des donnees (un programme), deplace des donnes de la RAM vers les registres, des registres vers les bus materiels, etc, etc. Tout ca ressemble a un OS.
En revanche, pour ce faire, il a fallu ecrire un interpreteur pour le langage machine, qui tourne dans le processeur. Ca ressemble encore a un OS.
En fait, meme si a priori, le compilateur parait indispensable, c'est beaucoup moins util qu'un OS. Le compilateur ne fait que fabriquer des programmes qui pourront s'executer. Son travail peut etre remplace par un cerveau humain. En 85, je faisais de l'assembleur en ecrivant mon code sur une feille de papier, puis en cherchant dans le bouquin de reference du MSX (assebembleur Z80) les valeurs hexadecimales des instructions, puis en les codant sous forme de chaine de caractere dans un programme en basic et en faisant un appel sur l'adresse des chaines de caractere. Dans ce cas, je me passais d'un compilateur, c'est mon cerveau qui faisait le travail. Mais tout ca n'aurait pas pu avoir lieu si je n'avais pas eu un OS, en l'occurence Microsoft MSX Basic.
Donc pour moi, la reponse est clairement que l'OS etait la avant le compilateur.
[^] # Re: sugestion
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis M3 est arrivé. Évalué à 3.
Cela dit, je ne sais pas comment ca se passe pour l'impression.
[^] # Re: Autre chose
Posté par Philippe F (site web personnel) . En réponse à la dépêche JUnitScenario 0.1 vient de sortir. Évalué à 8.
Le signification de test unitaire est acceptee par beaucoup de monde et signifie "tester independamment des morceaux de code". Le but est de mettre en evidence des problemes dans un morceau precis de code de facon a faire de la non-regression. Cette definition est supportee d'une part par les livres traitant d'extrem programming, d'autre part par la communaute et les outils de test unitaires.
Les tests fonctionnels ont un autre role: validation de l'integration de toutes les briques ensemble, stress de l'application par l'envoi de requetes en serie, reproduction du comportement d'un utilisateur.
Typiquement, comme te le dis le monsieur plus haut, creerClient va juste generer une requete SQL fictive et validera que la requete est ce qu'elle doit etre. Idem pour creerDevis. La conclusion logique, c'est que lancer l'un apres l'autre ne stresse pas du tout l'application car ce sont des tests _unitaires_
Maintenant, tu peux mettre en place des tests fonctionnels, en t'appuyant aussi sur Junit et les executer via un scenario. C'est une bonne idee et je fais ca aussi dans mes projets. Dans ce cas, ton test creera effectivement une vraie base de donnee et reproduira le comportement d'un utilisateur.
C'est le fait que JUnit puisse etre utilise dans deux contextes differents (tests unitaires, tests fonctionnels) qui seme la confusion ici.
En continuant a appeler ton projet JUnitScenario, tu risques de ne pas du tout faire comprendre l'utilite de ton soft (donc tu peux oublier les contributeurs):
- les gens qui ne connaissent rien au test unitaire ne seront pas interesses
- les gens qui connaissent les tests unitaires comme moi trouveront ton bidule inutile.
Je te conseille donc pour le bien de ton projet de faire bien comprendre le message. Qqch comme:
"JunitScenario builds an automation framework on top of JUnit to perform functional tests and stressing tests".
Une fois que ce point la est eclairci, ton projet devient interessant.
Mais si tu veux, tu peux continuer a appeler test unitaire un test fonctionnel. Tu peux aussi appeler le soleil "Lune". Mais ca reste le soleil et personne ne te comprendra.
[^] # Re: Que de souvenirs
Posté par Philippe F (site web personnel) . En réponse au journal Vous connaissez JavaCard ?. Évalué à 3.
[^] # Re: L'arbre qui cache la forêt
Posté par Philippe F (site web personnel) . En réponse au journal Je n'utilise plus Linux mais.... Évalué à 4.
Il y a d'autres parties dans KDE qui dependent des atomes X mais je ne suis pas assez pointu pour te dire lesquelles. Il me semble que la gestion de la session et la creation des repertoires temporaires utilisent partiellement des petits mecanismes de X
[^] # Re: Autre chose
Posté par Philippe F (site web personnel) . En réponse à la dépêche JUnitScenario 0.1 vient de sortir. Évalué à 3.
La somme des tests unitaires ne constitue pas un test fonctionnel. Il faut mettre son grain de sel (sa connaissance du fonctionnement du bazar) dedans. Dans mon experience, on s'appuie sur les mecanismes mis en place lors des tests unitaires, mais on ne re-utilise pas les tests unitaires tel quel.
C'est un peu comme la generation automatique de test unitaire a partir des headers. C'est genial sauf que 50 tests unitaires auto-generes ne peuvent remplacer des tests ecrits par le developpeur, qui va tester la ou ca fait mal.
Ce que tu me decris me semble plus facile a mettre en place avec un vrai test, fait non pas d'assemblage de tests unitaires, mais de reproduction du comportement d'un utilisateur.
[^] # Re: L'arbre qui cache la forêt
Posté par Philippe F (site web personnel) . En réponse au journal Je n'utilise plus Linux mais.... Évalué à 6.
[^] # Re: L'arbre qui cache la forêt
Posté par Philippe F (site web personnel) . En réponse au journal Je n'utilise plus Linux mais.... Évalué à 4.
# Qt, c'est fun
Posté par Philippe F (site web personnel) . En réponse au journal QT, KNUT && programmation. Évalué à 4.
Sinon, il existe un forum en francais
http://prog.qt.free.fr/portal.php(...) et un certain nombre d'autres en anglais (qt-forum.org) pour trouver de l'aide. Il y a aussi des bouquins mais je ne crois pas qu'il y aie une version recente en francais.
Pour ce qui est de la transition MFC -> Qt, le site que tu donnes propose un outil qui te permettra de recuperer les parties graphiques d'une appli MFC (dialogue, ....) mais ne transformera pas le code. Cela dit, c'est beaucoup plus simple et plus propre de programmer un MFC qu'en Qt, donc tu ne devrais pas avoir de probleme.
Le site de Trolltech propose aussi de nombreux trucs pour passer de MFC a Qt.
[^] # Re: Autre chose
Posté par Philippe F (site web personnel) . En réponse à la dépêche JUnitScenario 0.1 vient de sortir. Évalué à 3.
En jetant un coup d'oeil rapide, j'ai strictement rien vu de neuf donc je suis un peu sceptique.
[^] # Re: naturellement...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Déclarations de Microsoft à propos de l'interopérabilité, et réactions. Évalué à 10.
Avoir une doc decrivant un format, c'est la base de l'interoperabilite.
Avoir les sources, ca rend possible une demarche tres couteuse et sujette a erreur vis a vis de l'interoperatbilite. Je dois lire 10 000 lignes de code pour savoir que le bit X du byte Y correspond a la fonctionnalite Z ? Et que se passe-t-il si il y a une erreur d'implementation ? Comment tu montes tes tests de compabilite ?
Le garant d'une interoperabilite, c'est une documentation decrivant un format.
L'exemple emblematique etant OpenOffice, qui bien qu'ayant de tres bon filtres pour les documents word, est absolument inutilisable en terme d'interoperabilite sur ce point. Le code n'est tout simplement pas re-utilisable tel quel et imbitable.
[^] # Re: Quelle incompetence...
Posté par Philippe F (site web personnel) . En réponse au journal KDE porté vers Windows.... Évalué à 5.
J'ai ete supris de recevoir un coup de fil: il s'est renseigne et va publier un correctif demain, et il me demandait quelques conseils. Finalement, ca fait de la pub a KDE.
[^] # Re: Stop !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
> libre sinon il y aurait plus de tests unitaires dans le logiciel libre.
Affirmation gratuite et mechante. Va voir sur ma page web, je fais du logiciel libre. Meme si ce n'est pas la prochaine killer app, je suis content et fier de ce que je fais. Et yzis a le potentiel pour etre la killer vim app.
L'engouement pour les tests unitaire est recent. Perso, j'ai decouvert ca il y a 3 ans avec XP. Je pense que c'est un peu similaire pour les autres ici. Donc je n'ai integre la notion dans mes projets libres que depuis 3 ans.
Mais depuis que je m'interesse au sujet, il y a plus de test unitaires dans le monde du logiciel libre. J'ai fait un qtunit (pas forcement mon meilleur projet), une suite de test unitaires pour lua (c'est deja mieux).
J'ai fait tous les tests unitaires et leur conception pour l'OS open source pour carte a puce jayacard (jayacard.sf.net).
Yzis beneficies d'une suite de test en C++ et d'une suite de test en lua, devines de qui elle vient ? C'est d'ailleurs une des raisons pour lesquelles il sera un meilleur editeur que vim a terme.
[^] # Re: ???
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 4.
> tu dépends d'un automate qui t'envois 200 autres paramètres,etc
Je doute que tu arrives a gerer tes 300 parametres et tes 200 autres avec une seule fonction. Tu as forcement un decoupage du travail qui t'oblige a separer les taches. Une fois que tu as isole les taches, tu peux les tester individuellement.
> Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
En general c'est mieux d'avoir un simulateur sous la main, pour reproduire les cas pourris. J'en ai rarement vu dans le libre malheureusement.
> Dans certain cas tu n'as pas le choix. Une équipe développe l'applis, une autre bosse sur un automate qui va utiliser des
> appareils à plusieurs millions d'euro qui sera disponible que lorsque les développements sont terminés.
Parce que ca vaut plusieurs millions d'euro, tu crois qu'on ne peut pas faire de test ? Ou bien que je vais me dire "la vache, si ca vaut aussi cher, vaut mieux ne pas tester" ? Ton appareil, il a des entrees/sorties qui sont specifiees. Ben tu les utilises pour tes tests.
Tout ce qui a une api peut avoir un test.
> Mais je ne me vois pas demander au boss d'avoir 6 mois de plus
> pour faire des tests unitaires exautifs sans que ça apporte un réel intérêt.
Affabulation. Faire des tests unitaire te fait gagner du temps. Pas le jour ou tu les ecris, mais 6 mois plus tard, quand tu dois modifier le code que tu as ecrit. Tu es bien content de ne pas faire un audit complet de ton code pour verifier que le bug X n'a pas pete ton produit. Tu fais retourner ta suite de test, et hop, tu es tranquil. Les endroits ou ton produit est pete sont clairement isole.
Les tests unitaires, c'est une machine a gagner du temps. Je suis d'accord que c'est contre-intuitif comme idee, mais c'est vraiment le cas dans la pratique.
> Il faut alors que les éléments critiques soient simples.
C'est en effet la caracteristique d'une conception robuste.
> Ainsi tu peux "blinder" les tests unitaires et faire des tests exautifs sur les éléments critiques.
Ah, tu vois qu'on se comprend finalement.
> "Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Je ne suis pas d'accord. Pour tout projet de plus d'une heure, les tests unitaires te feront gagner du temps. Pour un projet typique, on code 80% du projet en 20% du temps. Les 20% restants sont les plus durs: bugs d'integration, ajustement de la conception, ...
Avec des tests unitaires, t'as plutot une progression lineaire de facteur 1: 20% du temps, 20% du projet. 50% du temps, 50% du projet. Evidemment, vous ne regardez que les 20 premiers % en disant "putain, je pourrai deja en etre a 80% et je n'en suis qu'a 20%". Mais au final, les dernier % sont torches a vitesse grand V. Tu peux meme te permettre de faire des changements majeurs dans le projet dans la phase finale pour integrer la derniere idee du mec marketing, sans avoir peur de miner ton produit. Alors qu'en general, les devs ne veulent plus toucher a rien dans la phase finale, parce qu'ils ont eu trop de bugs d'integration.
> - Faire un (ou des) test unitaire complet pour gecko
Comme je l'ai deja dit, les developpeurs de gecko font deja leurs tests. Ils ont plein de bouts de code qu'ils utilisent pendant leur dev. Seulement des qu'ils estiment que ca marche, au lieu d'integrer ces bouts de code dans une suite de non-regression, ils jettent.
C'est la qu'on perd du temps. Des choses qui sont developpees mais pas integree au produit. C'est sur que rajouter les tests apres, c'est tres difficile et tres couteux.
> Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Beaucoup moins que pour corriger les bugs de non- regression, pour relire le code et se prendre la tete a essayer de comprendre pourquoi la foncttion X est comme ca sans avoir le test qui explique et qui valide son comportement.
Il est evident cependant que les tests evoluent avec le soft. Mais c'est une bonne chose.
> Une fois que tu as évaluer les ressources nécessaires interroges si un développeur de plus uniquement pour faire
> de l'audit de code n'est pas un meilleur investissement.
Moi je m'interroge en terme de certitude.
- un developpeur qui audite le code: "je pense que ca marche"
- un test unitaire qui valide le code: "je suis sur que ca marche".
Il n'y a pas photo, je prend la 2e option.
> Mais parfois un module développé n'est utilisé que bien des mois après. [...] Mais suppose que les formats d'entrés aient légèrement
> changé et que lors des tests (pas des tests unitaires) ça plante un module développé il y a quelque mois. Ces "bricoles" ça arrive.
Non ? Tu m'apprend quelque chose, je croyais que tout marchait tout seul et que les tests ne servait qu'a valider la perfection du code que ton cerveau surpuissant avait deja garanti de toute facon.
Mais bien sur que ca arrive ! Et bien tu fais evoluer tes tests, en meme temps que ton module. Un principe de codage fondamental de XP, c'est "on ne code qqch qu'une seule fois". Si ton format change, tu modifies la fonction de lecture du format et le test correspondant. Hop. Si ta representaiton interne doit changer aussi, ben pareil, tu modifies les deux. Une fois que tu as fait ca, tu verifies que tous les modules affectes indirectement par tes changements fonctionnent encore. Tu fais un audit rapide de ta couverture de test sur ces modules. Si elle est bonne, voila, tu t'es economise quelques jours de prise de tete d'audit de tous les modules qui utilisaient ton code.
> Ça arrive car les tests peuvent être erronés ou incomplet, car il y a eu un manque communication lors de l'évolution d'un module, etc.
Bien sur, ca arrive tous les jours. Mais les tests ne sont pas graves dans la pierre, ils evoluent en meme temps que ton programme te que tes specs.
> Toi t'es dans le rève ou il n'y a pas d'erreurs de conception,
Pas du tout. Je passe meme une grande partie de mon temps a corriger mes erreurs de conception en faisant evoluer mes tests. Le fait d'etre un mauvais concepteur ne me gene pas, car j'ai de bonnes suites de tests.
> il n'y a pas de manque de communication, le projet est parfaitement géré, les tests sont tous exautifs et parfait, les
> spécifications sont complètes et n'ont raté aucuns scénarios, etc.
Si c'etait ca, je n'aurai pas besoin d'ecrire des tests. Au contraire, les tests m'aident a gerer tous les problemes classiques d'un projet de facon beaucoup plus zen:
- spec qui evolue => je fais evoluer mes tests
- module non encore dispo => je fais des tests et un simulateur pour le remplacer
- bug a la con decouvert => je fais un test pour encadrer le bug et je cherche tous ses cousins possibles, puis je corrige
- probleme d 'integration dans un autre module, on ne sait pas d'ou vient le probleme => je montre mes suites de test a l'autre developpeur, qui est ensuite convaincu que le probleme vient de son cote
- procedure ISO a suivre pour la validation des specs => j'associe a chaque fonctionnalite un test et mon rapport de test devient ma doc de validation
- je trouve un module super difficile a developper et a tester => c'est un signe de mauvaise conception, je le decoupe jusqu'a pouvoir le tester facilement
- on me dit que a la convergence de trois conditions tres tres rares, le soft ne marche pas => je modifie mon simulateur (pratique de l'avoir developpe avant) pour inclure ces conditions tres tres rares.
etc etc.
Les tests unitaires, c'est vraiment une methodologie de developpement qui me permet d'etre super zen dans ce que je fais et de gerer tous les problemes quotidiens avec du recul.
> Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Mon cauchemard, c'est les developpeurs qui pensent que leur cerveau demesure ne pond que du code correct.
Perso, je suis modeste et pessimiste. Je pense que le code que j'ecris ne marche pas. Alors, je cherche des preuves.
> Mais je vais te montrer un cas "spécial" et qui va te montrer que je ne suis pas contre les tests unitaires lorsque ça a un sens.
De fait, si tu les as utilise et que tu as vu leur valeur, je ne comprends pas pourquoi tu me critiques de facon aussi acharnee.
> J'ai réalisé les procedures de tests exautives (car c'était possible et ça permettait aussi de faire le recette auprès du client).
Ca rejoint ce que je disais sur la valeur des tests. Ca sert plus qu'au developpeur.
> Retard : 15 jours.
Chapeau!
> Le client ne s'est jamais plaint d'un bug.
C'est la caracteristique d'un programme avec de bons tests unitaires. Tres peu de bugs.
> Tous les tests ont été réalisés à la *fin* car pour *ce* projet c'était une bonne méthode.
Je pense que tu as pris des risques sur ton projet, que tu mesurais de facon consciente. Il aurait pu t'arriver des problemes, genre le client reviens au bout de 4 mois : "donnez nous ce que vous avez fait , et on arrete le projet. Puisque ca fait 4 mois que vous avez commence, vous en etes a la moitie. On paiera que pour ce qui marche uniquement".
Mais je ne critique pas ta demarche. C'est bien que tu aies reussie a faire ce qui paraissait impossible.
[^] # Re: ha ?!??
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 5.
> leur gout et il pense que ça leur donne le droit de critiquer le libre dans son ensemble.
Je fais du logiciel libre et j'accepte les critiques. Je ne comprends pas pourquoi il n'en irait pas de meme de mes pairs developpeur. Refuser la critique, c'est toujours une forme d'extremisme. Accepter la critique et dire "ta critique est infondee" ou "ta critique est fondee mais ca restera comme ca", c'est de l'ouverture d'esprit.
Un logiciel est un outil, quand l'outil est pourri, il est juste de le critiquer. Si tu vois le logiciel comme une oeuvre d'art qu'il ne faut jamais executer parce qu'il plante, libre a toi. Mais si tu vois le logiciel comme un outil, tu dois etre pret a accepter la notion de critique, independamment de la facon dont ce soft a ete developpe.
[^] # Re: ???
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
Je sais pas d'ou tu sors ca, je ne suis pas d'accord. Dans le cas des lib pourries et mal documentees, le developpeur est contraint de chercher dans les headers.
Dans les libs que j'utilise, les docs sont bien faites et je ne vais jamais chercher dans les headers:
- boost
- qt
- python
- lua
- KDE
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
Et oui, mais l'equipe des developpeurs change. Les anciens s'en vont, ces nouveaus les remplacent. C'est encore plus vrai en entreprise. La suite de test garantit que le qualite demeure dans le projet et pas seulement dans l'individu qui l'a code.
> (donc la batterie de tests codée après coup ne servira à rien par la suite).
C'est pas vrai. A la prochaine attaque sur URL, le code gerant les URL sera encore change. Il se peut qu'a ce moment, un developpeur introduise par megarde une modif qui enleve la correction precedente. Ca n'arrivera peut-etre pas mais tu n'as aucune garanti. Avec ta suite de test, tu as une garantie.