Bon j'ai fait la manip' "java -jar Trivial.jar", mon programme s'est exécuté dans le terminal, les "é" et autres ne passent pas c'est dommage...
Mais bon quand je fais un double-clic sur le fichier .jar en lui même, rien ne se passe, j'ai loupé un truc ?

Inhert- Je ne suis qu'en première année, je n'ai pas encore vu les interfaces graphiques, j'ai juste vu un tuto avec swing où il est question d'une calculatrice...

Et quand je dis que je n'ai pas de bug, je veux dire que mon programme va de A à Z sans soucis, mes requêtes SQL marchent, les joueurs ont bien leurs points comptés etc...
Mais après tu veux peut-être parler d'autre styles de bug, donc là on ne doit pas parler de la même chose, le fait est surtout que je ne suis qu'en 1ère année et que je suis très limité au niveau de mes connaissances malheureusement...

Je vais regarder JUnit, voir en quoi ça consiste, merci du tuyau.

Non, je pense que ton programme se lance bien, mais que tu ne le vois pas car il n'est qu'en "System.out", et rien d'autre.
Donc, en regardant les processus, tu dois en avoir un qui tourne, correspondant à ton logiciel.

C'est ce que je me disais aussi, j'ai bien l'impression qu'il se lance (il y a le chargement à coté de ma souris quand je double-clic), or il apparait pas, bon pas bien grave je regarderai dans les processus, merci du conseil.

Normal, il faut faire la manip' sur la variable d'environnement Path.

La variable d'environnement path ?
Où se trouve elle ?

Tu sais PayGleuh ... s'il arrive à faire un "java -jar sonJar" dans la console ... c'est que le path est correctement rempli pour avoir accès à la commande "java".
À moins que tu ne pensais à autre chose, mais je n'ai jamais vu le couple "Java" et "Path" autrement que pour ça.

Megatotor:

Ok donc apparemment t'as encore rien vu niveau tests. Tu fais quelle option? Si tu prends l'option prog tu en auras peut-être en deuxième année.

Si tu veux atteindre un niveau pro tu n'y échapperas pas à un moment ou un autre

En gros tu n'as pas fait de "vrais" tests au sens pro. Les "vrais" tests c'est quelque chose d’exhaustif. Tu dois tester tout les cas possible, tout les cas limites auquel on ne pense pas etc...

On est censé faire des tests unitairement, c'est à dire tester chaque méthode séparément, et ce de manière indépendante au contexte, donc pas dans une classes classiques avec un main.

Et derrière il y a tout un tas de méthode à connaitre pour savoir quoi tester, comment bien tester, etc...

Dis toi que dans un test exhaustif, tu dois tester chaque chemin d’exécution possible dans tes méthodes, donc à chaque if, else que tu rajoutes, ça rajoute des tests en plus!

Bien sur à ton niveau, couvrir uniquement genre 60/75% des cas avec des tests JUnit basiques suffira mais je pense que ça sera un gage de qualité pour ton projet... Si tu continues en prog tu réaliseras à quel point ces tests sont importants!

Après faut voir si tu as le temps ou pas! Même si tu n'as pas besoins d'une super suite de test, il faudra te documenter un minimum pour faire quelque chose de pertinent... D'ailleurs, si ton code est vraiment trop mal architecturé, c'est peut-être pas pertinent parce que ça peut-être vite pas très testable du coup... Rassures-toi, en première année de SIO c'est normal.

"En gros tu n'as pas fait de "vrais" tests au sens pro. Les "vrais" tests c'est quelque chose d’exhaustif. Tu dois tester tout les cas possible, tout les cas limites auquel on ne pense pas etc..."

Ca c'est ce que les gens naif pensent. Une vraie application est typiquement bien trop complique pour pouvoir tester tous les cas limites. Du coup on couvre les cas auquel on pense et qui semblent important. Et on laisse le reste a la posterite.

je plussoie godrik. Parfois, on a pas le temps de faire des tests pour tous les cas, il faut pour celà encoder tous les cas de test et pouvoir les jouer automatiquement et rapidement. Ce n'est pas toujours possibles pour de gros systèmes, et surtout les managers veulent qu'on teste automatiquement mais ne comprennent pas la charge que celà implique

Ahah +1 godrik et Silvermo... c'est plutôt l'inverse en fait les unit tests c'est bon pour l'école, la réalité est "malheureusement" toute autre. A moins d'avoir des projets parfaits, la pression commerciale est toujours telles que les unit tests passent à la trappe lors des dernières étapes. Et dans tous les cas dans la réalité la plupart des programmeurs ne testent pas tous les cas, il faut savoir que le plus important dans les unit tests ce n'est pas vraiment de tester ton propre code mais c'est d'assurer la conformité à un scénario et donc normalement assurer une sécurité et une stabilité lors d'un éventuel refactoring ultérieur. C'est ça la vraie utilité des unit-tests.

Je plussoie...
Et en plus, maintenir les tests unitaires.. peut s'avérer une plaie ...

Encore ce jeudi, j'ai découvert un bug dans l'application de ma boite, un bug vieux de plus d'un an, pour une application qu'on a mis en production il y a un an et demi, et grâce à laquelle des millions de dossiers ont déjà été créés.
Un bug survenait au niveau DB, et aucune trace dans la table message_log habituelle où étaient envoyés les messages d'erreur et debug de nos packages PL SQL...

Aucune trace non plus au niveau du serveur... à part le code de l'erreur oracle remontée par le package PL/SQL...

Bref, heureusement qu'il me restait la version "JSON" de l'objet java tel qu'il était avant d'être converti et envoyé au package plsql...
après, ça a été une heure et demie d'encodage champ par champ pour recréer le cas de test...
et heureusement cela a permis de dénicher le bug...

Mais comme quoi, le manque de tests unitaires, dans ce genre de cas, ça fait pleurer

Lien permanent

godrik Voir le profil de godrik
Posté le 9 juin 2012 à 01:34:08 Avertir un administrateur
"En gros tu n'as pas fait de "vrais" tests au sens pro. Les "vrais" tests c'est quelque chose d’exhaustif. Tu dois tester tout les cas possible, tout les cas limites auquel on ne pense pas etc..."

Ca c'est ce que les gens naif pensent. Une vraie application est typiquement bien trop complique pour pouvoir tester tous les cas limites. Du coup on couvre les cas auquel on pense et qui semblent important. Et on laisse le reste a la posterite.

Oui enfin tu m'avais compris. Évidement, que quand j'ai des tonnes de chemins logiques avec 25 000 combinaison possibles, non je vais pas tout tester...

Pour le niveau de l'auteur, je me contentais de lui dire "pense au plus de cas possibles dans ta tête de ce que va faire l'utilisateur", je ne lui suggérais pas de dessiner le graph de flot de contrôle à la recherche de tout les chemins logiques hein...
Je mettais juste les points sur les i, parce que beaucoup d'étudiants se contentent limite d'appeler la méthode et de vérifier que ça plantent pas...

(c'est pour ça que je suggérais que 60% pour son petit machin serait déjà bien)

De toute manière la couverture de code n'est pas le seul critère de qualité des tests, on peu très bien avoir des tests de 100% moisis et d'autres de 75% très bien...

"A moins d'avoir des projets parfaits, la pression commerciale est toujours telles que les unit tests passent à la trappe lors des dernières étapes. Et dans tous les cas dans la réalité la plupart des programmeurs ne testent pas tous les cas"

Justement c'est ça qui est dommage.

Les tests c'est chiant au début, après ca fait quand même bien gagner du temps plus tard. Parce que le temps que vous économisez à ne pas tester, vous le perdez à débugger, regardez ce pauvre Silvermo qui à du passer 1h30 à déboguer. Et déboguer, c'est supra-chiant.

Perso, j'aurais du mal à m'en passer aujourd'hui. Au moins un peu... Après les mentalités et les formations évolues, je pense que le développement piloté par les test ça à de l'avenir... Mais ca, ça nécessite de penser différemment, c'est plus ça qui est compliqué.

le développement piloté par les tests c'est faisable quand y a pas des impératifs de vouloir toujours faire plus avec moins...
Et enfin, la complexité de la mise en place des tests unitaires dépendra beaucoup d'un projet à l'autre.
Ecrire des tests unitaires, c'est facile pour des classes utilitaires. Mais pour toute une application, pas évident.

Perso, sur une architecture MVC je ne fais des tests que sur le package métier, pas sur les contrôlers et encore moins sur les interfaces graphique (même si je sais que ça existe).

Evidement que les tests unitaires sont utiles. Mais les comportement d'une applications entieres sont souvent impossibles a tester. On a mis en service une application de recommendation d'article scientifiques. Les algos de recommendations sont compliques, les entrees peuvent etre fait dans 4 ou 5 format differents. C'est un site web donc potentiellement visible avec une dizaine de navigateurs differents.

Comment tu testes un truc comme ca? Comment tu testes les problemes de charge utilisateur, tu peux faire un test basique avec une simple boucle qui envoye 1000 requetes au serveur. Ca rassure. Mais comment tu verifie que les resultats sont coherent? Bah tu le fais pas. Comment tu verifie que l'algo recommande un truc qui a du sens. Ca pour le coup tu le fais a la main. Comment tu verifie la conformite au 500 cas. Particulier bizarre de tes formats d'entrees? Bah tu le fais pas non plus, tu verifies qu'un ensemble de fichier concotter a la main est bien parsee, et tu prie tres fort.
Comment tu verifies les affichages sur les differents navigateurs web? Bah ca non plus tu le fais pas. Tu teste sur une dizaine de machine et tu dis que ca ira bien comme ca.

Et meme a l'echelle unitaire. Au niveau de l'algo, comment tu teste une implementation d'un algo comme page rank? Soit tu construit un graphe a la main et ca veut rien dire. Soit tu fais tourne sur des vrai donnee et ta somme de page rank n'est pas 1.0 a cause de l'innapproximation flottante.

Serieusement sur une appli reelle, c'est impossible d'avoir des tests qui couvrent correctement ton code. Tu couvre les grands cas d'utilisation et tu attends les rapport de bugs pour le reste.

Et je ne parle pas du temps de faire tourner tes test non plus. J'ai des tests pour des algo bizarres qui sont important et irreductible. Le test tourne 3 a 4 heures. I'll faut avoir le temps et les ressource pour faire tourner un truc comme ca. En pratique tu les fais tourner avant de releaser et de temps en temps pendant ton circuit de developpement.

+1 godrik. On ne peut couvrir que quelques cas extrêmes ou courants, mais jamais l'ensemble.
Et comme tu dis, faut encore vérifier les résultats...
Et ce qui est encore mieux.... c'est quand les analystes viennent voir les développeurs pour demander qu'on fasse ce que l'ancienne application faisait.
Et les tests utilisateurs se ramenaient alors à comparer les résultats entre la nouvelle et l'ancienne application... -_- , du moins la partie visible (GUI);

Pour l'application qu'on développe dans ma boîte, je ne peux pas imaginer qu'on puisse rejouer tous les cas de test facilement.
Déjà, les données sont différentes d'un environnement à l'autre (DEV, INT, ACC, TRAINING, PROD)... et il manque des cas de test dans certains environnement, ça ne facilite rien...
Secundo, pour tester le GUI en automatisé, c'est pas évident, car notre GUI est construit dans une Chrome Frame contenue dans IE.
On utilise en effet IE qui est le seul compatible avec un CRM qu'on nous force à utiliser, et dans lequel on construit nos applications... :/ ...

Enfin ça facilite rien tout ça ^^ ...
Enfin y a des contraintes du genre : ne pas créer deux fois le même dossier en moins de cinq minutes... donc faut qu'on joue des cas de test très variés mais toujours valides (càd des clients dans un certain cas, avec des contrat dans un certain état...) , et vu que les données changent tous les jours, et que l'application réagit différemment en fonction des données dans le GUI et des données provenant d'autres systèmes d'information, on ne peut pas prévoir facilement le résultat... ni le vérifier aisément.

Bref c'est très utopique

Houlà je vois que ça discute beaucoup ^^
Donc pour info il ne me reste que 3 semaines là, et maintenant mon objectif est de créer, du moins essayer de faire une interface graphique, je doute y arriver car je n'ai jamais vu ça à mon niveau, je ne sais même pas par quoi commencer...

Et sinon je suis bien en option développement, donc je verrai certainement les moyens de tester son code, mais bon, là pour mon projet actuel...je ne sais pas si cela en vaut réellement la peine...je pense que l'interface graphique est une priorité.

Donc maintenant j'ai installé NetBeans, ce logiciel a t-il un réel avantage par rapport à eclipse ? Pouvez vous me donner quelques pistes à suivre pour bien débuter le développement de mon interface graphique ?

Je pense contacter ma prof de développement pour lui montrer où j'en suis, en espérant qu'elle me guide un peu...

Netbeans te met à disposition le merveilleux outil Matisse , pour construire les interfaces graphiques juste avec la souris, c'est son gros avantage.
Bon l'inconvénient étant que une fois que tu repasses à autre chose que Netbeans, ton code (ou plutôt tes fichiers de propriétés du GUI) généré par Netbeans précédemment fonctionne toujours mais vas y pour le lire ^^ ...

Sinon les deux se valent, Eclipse et Netbeans.
j'ai fait mes études avec Netbeans, et je travaille depuis deux ans en milieu professionnel avec Eclipse.
Les deux sont très puissants, fonctionnels... y a pas de souci pour ça.

Désolé du double post, mais je vois que vous avez l'air de travailler dans des entreprises dans le développement informatique, cela m'intéresse beaucoup, est ce que vos entreprises prennent les stagiaires ? car c'est très difficile de trouver des stages dans ce genre d'entreprises malheureusement...
j'ai un stage l'année prochaine à faire en janvier, si certains d'entre vous pensent qu'il y aurait moyen que leur entreprise acceptent les stagiaires, je suis ouvert pour prendre des coordonnées ou autres.

merci à tous pour votre aide en tout cas, ça fait plaisir de se sentir épauler par des connaisseurs.

Silverno outils Matisse ? D'accord je vais regarder ça alors, merci du conseil