• [^] # Re: Les vrais ajouts

    Posté par . En réponse au journal Java 7 est dispo !. Évalué à 2.

    Les tests unitaires, c'est certes tres pratique, mais leur gros probleme, c'est qu'ils sont justement unitaires.

    Tu peux ajouter des tests fonctionnels, ce n'est pas exclusif.

    J'ai du mal a comprendre la logique en fait, une approche permet de trouver des bugs a coup sur tres tot, avant meme que le dev ait commite.
    Quelle est le probleme avec au juste?

    Dans l'absolu, aucun. Le problème c'est avec la version Java de cette approche :

    • il y a une phase de compilation explicite
    • la verbosité du langage est largement augmentée (noms d'identifiants à rallonge, pas d'inférence de type...)

    Je suis bien d'accord que ce n'est pas inhérent à l'approche décrite, mais on parle bien de Java, pas d'un langage idéal.

    Ca remplace pas la doc, mais ca permet de comprendre plus facilement (universal_newline est achement plus comprehensible que u).

    open() étant une fonction super utilisée, je ne vois pas pourquoi le programmeur lambda ne finirait pas par reconnaître les trois ou quatre options d'ouverture possibles.

    Encore une fois, c'est comme ls. Tu as le droit de préférer listDirectoryContents --verbose-listing, mais je crois que la plupart voudront continuer à utiliser ls -l.

    Et penser que les tests unitaires vont couvrir 100% des chemins, c'est pas naif?

    Si, c'est naïf (ou, plus exactement, ce qui est naïf est de croire que 100% de couverture permet de détecter tous les bugs). N'empêche que les tests permettent de détecter et de prévenir des bugs beaucoup plus "intéressants" (lire : tordus) que la compilation.