Je souhaite présenter un devoir à rendre en Java en mettant en avant le
fait que j'ai fait une programmation dirigée par les tests.
Il faudrait que les tests soient dans un fichier séparé (en fait dans un
réperoire séparé même).
Par exemple:
$HOME/
src/
Pair.java
tests/
Tests.java
Supposons que dans Pair.java il y ait une fonction:
public static int generatePairNumber(void)
{
...
}
Il faudrait que dans Tests.java je puisse solliciter cette fonction, mais
je ne sais pas comment faire.
Bon. Je n'ai qu'un semestre de Java à mon actif, et avec les évènements
récents, pas beaucoup d'heures de pratique.
Merci de votre aide.
On Thu, 23 Mar 2006 13:50:03 +0100, alexandre cartapanis wrote:
Faire du développement orienté test ne s'improvise pas, surtout en java.
Oui, mais de toutes façons, il faut apprendre avec des cas simples. Je ne souhaite pas commencer tout en étant assisté par des assistan ts en tout genre.
Un petit conseil, utilise un framework adapté. Je te conseille JUnit qui est très utilisé (et donc tu pourras le mettre sur ton CV :)) et r éputé parfaitement mature. Tu va gagner un temps énorme.
Le temps passé à apprendre n'est pas toujours perdu.
Non, mais le temps perdu a "ré-inventer la roue" l'est souvent.
Deuxième chose, le développement orienté test a été "théor isé", dans une méthodologie nommée eXtreme Programming, ou XP (entre autre). Cher che aussi de ce coté la...
C'est exactement ça. Mais comme je m'annonçait comme "débutant", je ne voulais pas "me la péter" avec des termes techniques. Le but est vrai ment de voir les choses au niveau élémentaire: - import de fichiers - Makefile basique - test unitaires très basiques aussi
Justement, le principe de l'XP (et accessoirement des tests unitaires) est de gagner du temps. Si tu en perds a rédiger tes test, alors ça n e sert plus a rien.
JUnit ne fais pas les test à ta place. Par contre, il t'aide a les rédiger plus vite et mieux, en se concentrant sur l'essentiel (a savoir les tests eux même). Pour tout ce qu'il y a "autour" des tests (exécution de ces tests, création et visualisation de rapport de test , ...), il le fais mieux que tu ne pourras jamais le faire (a peu de chos e près :)).
D'après ton discours, ta démarche est avant tout didactique. Il s'agi t de tester des technologies et/ou des méthodes. Dans ce cadre, il me semble plus intéressant et avantageux pour toi de passer par JUnit. D'autant que celui ci n'est VRAIMENT pas compliqué, et très très fa cile d'accès. Sans compter l'avantage d'inscrire de tel outil a ton CV...
-- Alexandre CARTAPANIS - Responsable Système et Réseau Email Gsm. 06 72 07 51 55
On Thu, 23 Mar 2006 13:50:03 +0100, alexandre cartapanis wrote:
Faire du développement orienté test ne s'improvise pas, surtout en java.
Oui, mais de toutes façons, il faut apprendre avec des cas simples.
Je ne souhaite pas commencer tout en étant assisté par des assistan ts en
tout genre.
Un petit conseil, utilise un framework adapté. Je te conseille JUnit qui
est très utilisé (et donc tu pourras le mettre sur ton CV :)) et r éputé
parfaitement mature. Tu va gagner un temps énorme.
Le temps passé à apprendre n'est pas toujours perdu.
Non, mais le temps perdu a "ré-inventer la roue" l'est souvent.
Deuxième chose, le développement orienté test a été "théor isé", dans une
méthodologie nommée eXtreme Programming, ou XP (entre autre). Cher che
aussi de ce coté la...
C'est exactement ça. Mais comme je m'annonçait comme "débutant", je ne
voulais pas "me la péter" avec des termes techniques. Le but est vrai ment
de voir les choses au niveau élémentaire:
- import de fichiers
- Makefile basique
- test unitaires très basiques aussi
Justement, le principe de l'XP (et accessoirement des tests unitaires)
est de gagner du temps. Si tu en perds a rédiger tes test, alors ça n e
sert plus a rien.
JUnit ne fais pas les test à ta place. Par contre, il t'aide a les
rédiger plus vite et mieux, en se concentrant sur l'essentiel (a savoir
les tests eux même). Pour tout ce qu'il y a "autour" des tests
(exécution de ces tests, création et visualisation de rapport de test ,
...), il le fais mieux que tu ne pourras jamais le faire (a peu de chos e
près :)).
D'après ton discours, ta démarche est avant tout didactique. Il s'agi t
de tester des technologies et/ou des méthodes. Dans ce cadre, il me
semble plus intéressant et avantageux pour toi de passer par JUnit.
D'autant que celui ci n'est VRAIMENT pas compliqué, et très très fa cile
d'accès. Sans compter l'avantage d'inscrire de tel outil a ton CV...
--
Alexandre CARTAPANIS - Responsable Système et Réseau
Email alexandre.cartapanis@macymed.fr
Gsm. 06 72 07 51 55
On Thu, 23 Mar 2006 13:50:03 +0100, alexandre cartapanis wrote:
Faire du développement orienté test ne s'improvise pas, surtout en java.
Oui, mais de toutes façons, il faut apprendre avec des cas simples. Je ne souhaite pas commencer tout en étant assisté par des assistan ts en tout genre.
Un petit conseil, utilise un framework adapté. Je te conseille JUnit qui est très utilisé (et donc tu pourras le mettre sur ton CV :)) et r éputé parfaitement mature. Tu va gagner un temps énorme.
Le temps passé à apprendre n'est pas toujours perdu.
Non, mais le temps perdu a "ré-inventer la roue" l'est souvent.
Deuxième chose, le développement orienté test a été "théor isé", dans une méthodologie nommée eXtreme Programming, ou XP (entre autre). Cher che aussi de ce coté la...
C'est exactement ça. Mais comme je m'annonçait comme "débutant", je ne voulais pas "me la péter" avec des termes techniques. Le but est vrai ment de voir les choses au niveau élémentaire: - import de fichiers - Makefile basique - test unitaires très basiques aussi
Justement, le principe de l'XP (et accessoirement des tests unitaires) est de gagner du temps. Si tu en perds a rédiger tes test, alors ça n e sert plus a rien.
JUnit ne fais pas les test à ta place. Par contre, il t'aide a les rédiger plus vite et mieux, en se concentrant sur l'essentiel (a savoir les tests eux même). Pour tout ce qu'il y a "autour" des tests (exécution de ces tests, création et visualisation de rapport de test , ...), il le fais mieux que tu ne pourras jamais le faire (a peu de chos e près :)).
D'après ton discours, ta démarche est avant tout didactique. Il s'agi t de tester des technologies et/ou des méthodes. Dans ce cadre, il me semble plus intéressant et avantageux pour toi de passer par JUnit. D'autant que celui ci n'est VRAIMENT pas compliqué, et très très fa cile d'accès. Sans compter l'avantage d'inscrire de tel outil a ton CV...
-- Alexandre CARTAPANIS - Responsable Système et Réseau Email Gsm. 06 72 07 51 55
J'ai oublié ton pb d'architecture, le mieux pour toi est d'utiliser deux packages differents correspondant à l'architecture de ton projet du genre: fr.tonnom.prog et fr.tonnom.tests
Ah non ca c'est le monde a l'envers. Ca veut dire que tu pollues ton repertoire source avec des tests.
Sur la plupart des projets bien structures ce que tu trouveras c'est:
src/ fr.tonnom.prog
et
testsrc/ fr.tonnom.prog
Et les bons environnements de developpement (p.ex. IntelliJ IDEA) permettent de "flagger" le repertoire src/ comme etant les "vraies" sources et testsrc/ comme etant les tests.
Ca simplifie aussi l'ecriture des taches Ant (sinon t'es oblige d'exclure les tests lorsque tu compiles, ou alors tu compiles les tests dans ton appli et ca c'est vraiment naze).
A+
fd wrote:
...
J'ai oublié ton pb d'architecture, le mieux pour toi est d'utiliser deux
packages differents correspondant à l'architecture de ton projet du
genre: fr.tonnom.prog et fr.tonnom.tests
Ah non ca c'est le monde a l'envers. Ca veut dire que tu pollues ton
repertoire source avec des tests.
Sur la plupart des projets bien structures ce que tu trouveras c'est:
src/
fr.tonnom.prog
et
testsrc/
fr.tonnom.prog
Et les bons environnements de developpement (p.ex. IntelliJ IDEA)
permettent de "flagger" le repertoire src/ comme etant les "vraies"
sources et testsrc/ comme etant les tests.
Ca simplifie aussi l'ecriture des taches Ant (sinon t'es oblige
d'exclure les tests lorsque tu compiles, ou alors tu compiles les
tests dans ton appli et ca c'est vraiment naze).
J'ai oublié ton pb d'architecture, le mieux pour toi est d'utiliser deux packages differents correspondant à l'architecture de ton projet du genre: fr.tonnom.prog et fr.tonnom.tests
Ah non ca c'est le monde a l'envers. Ca veut dire que tu pollues ton repertoire source avec des tests.
Sur la plupart des projets bien structures ce que tu trouveras c'est:
src/ fr.tonnom.prog
et
testsrc/ fr.tonnom.prog
Et les bons environnements de developpement (p.ex. IntelliJ IDEA) permettent de "flagger" le repertoire src/ comme etant les "vraies" sources et testsrc/ comme etant les tests.
Ca simplifie aussi l'ecriture des taches Ant (sinon t'es oblige d'exclure les tests lorsque tu compiles, ou alors tu compiles les tests dans ton appli et ca c'est vraiment naze).
A+
fd
Ah non ca c'est le monde a l'envers. Ca veut dire que tu pollues ton repertoire source avec des tests.
je suis d'accord avec toi, sauf qu' initialement la réponse s'adressait
à un débutant en java... Alors ok pour les good practices mais chaque choses en son temps? non ?
Ah non ca c'est le monde a l'envers. Ca veut dire que tu pollues ton
repertoire source avec des tests.
je suis d'accord avec toi, sauf qu' initialement la réponse s'adressait
à un débutant en java...
Alors ok pour les good practices mais chaque choses en son temps? non ?
Ah non ca c'est le monde a l'envers. Ca veut dire que tu pollues ton repertoire source avec des tests.
je suis d'accord avec toi, sauf qu' initialement la réponse s'adressait
à un débutant en java... Alors ok pour les good practices mais chaque choses en son temps? non ?
lewmania942
fd wrote:
Ah non ca c'est le monde a l'envers. Ca veut dire que tu pollues ton repertoire source avec des tests.
je suis d'accord avec toi, sauf qu' initialement la réponse s'adressait
à un débutant en java... Alors ok pour les good practices mais chaque choses en son temps? non ?
Ah oui tout a fait. En fait j'ai repondu a ton message "j'avais oublie ton pb d'archi" dans lequel le message original n'etait pas entierement quote, donc je n'avais pas tout vu.
On l'embetera avec les "good practices" plus tard ;)
A+++
fd wrote:
Ah non ca c'est le monde a l'envers. Ca veut dire que tu pollues ton
repertoire source avec des tests.
je suis d'accord avec toi, sauf qu' initialement la réponse s'adressait
à un débutant en java...
Alors ok pour les good practices mais chaque choses en son temps? non ?
Ah oui tout a fait. En fait j'ai repondu a ton message "j'avais oublie
ton pb d'archi" dans lequel le message original n'etait pas entierement
quote, donc je n'avais pas tout vu.
On l'embetera avec les "good practices" plus tard ;)
Ah non ca c'est le monde a l'envers. Ca veut dire que tu pollues ton repertoire source avec des tests.
je suis d'accord avec toi, sauf qu' initialement la réponse s'adressait
à un débutant en java... Alors ok pour les good practices mais chaque choses en son temps? non ?
Ah oui tout a fait. En fait j'ai repondu a ton message "j'avais oublie ton pb d'archi" dans lequel le message original n'etait pas entierement quote, donc je n'avais pas tout vu.
On l'embetera avec les "good practices" plus tard ;)
