J'ai découvert la prog qu'en cours : En classe on a fait un cours sur le C++ ce cours m'a bien plus
Mais bon chez moi quand je veut me lancer à la prog j'ai pas trop envie,j'ai rien pour me guider donc je laisse
Une fois j'ai tenté de crée un site mais j'ai lâché à la fin

Moi je trouve pas ça chiant du tout, au contraire.

Y'a un topic récent qui ressemble un peu au tien si ça t'intéresse: https://www.jeuxvideo.com/forums/1-31-8687702-1-0-1-0-vous-aimez-la-programation.htm

Au début, quand on connaît pas grand chose, ça peut être assez pénible d'apprendre, mais une fois qu'on connaît bien les bases, c'est vraiment fun de coder.

Bah ca depends de ce que tu fais et de pourquoi tu le fais. Perso j'aimerai bien avoir plus de temps pour programmer...

"Bah ca depends de ce que tu fais et de pourquoi tu le fais"

+1

Quand tu es sur un projet perso, et que les idées s'enchainent "tiens et si je rajoutais ça et ça... Et jvais mettre ça, dans le futur je pourai mettre ça"

Quand tu es en classe "Créez une classe voiture qui correspond au contexte de l'entreprise voiturix de l'énoncé, respectez la casse des méthodes de l'énoncé" ouai là c'est chiant

Surtout que en cours la solution pour ma part reste évidente car il suffit de lire le cours et tu n'a souvent qu'une façon de le faire celle du prof.
Alors que en solo moi j'ai une armée d'idée qui me viennent etc.

A moins d'être un programmeur servile sans idée et à la botte du chef de projet, si tu fait toi même tes programmes c'est un vrai travail de "création". Soit tu peu trouver ça chiant de peindre, de sculpter, d'écrire, de composer de la musique, de programmer, ... et pour d'autres c'est toute leur vie.

Donc soit tu as envie de programmer et c'est une passion, soit tu fuis l'informatique parce que si tu aimes pas ça c'est juste un cauchemar (bugs, pannes, évolution rapide des technologie, hackers, pression des clients/patrons, ...) , et tu fais autre chose. Il y à pas assez de bouchers par exemple, et je connais des bouchers qui gagnent le double de certains programmeurs...

Personnellement j'ai vraiment pris plaisir à faire un projet long pour la fac mais en faite il y a plusieurs étapes.

Debut : Chiant, car au final ça sert à rien et c'est moche
Milieu/Debut : Chiant car tu dois debug ce que tu as fait avant
Milieu/Fin : Enorme satisfaction de voir ton application comparer au début, et vu que tu as un base stable, toute les briques s'assemble et ca fait plaisir de voir que tu as tout fait bien avant, et c'est extrêmement facile d'ajouter des trucs
Fin: Chiant, car tu dois tout tester(surtout quand c'est un jeu d'échec ) et régler tout les bugs, et ne pas t'éparpiller

Voilà en gros le début c'est le plus chiant, mais une fois que tu as quelques chose qui ressemble à quelque chose e stable, tu es vraiment content de toi

Et je rajouterai que c'est comme peindre un mur

Le moment qui fait plaisir c'est quand tu met la couche final.
Mais avant tu dois préparé la zone, traité le mur, et mettre plusieurs couches.
Et à la fin tu dois tout ranger, et faire les finitions

"Fin: Chiant, car tu dois tout tester"

TDD, mon cher, TDD !
Enfin c'est peut-être pas applicable à ton langage. Mais si ça l'est, ça permet d'avoir une app bien plus robuste en général, éprouvée sur le long terme, et c'est moins chiant de faire petit à petit que tout à la fin. J'étais pareil, et le passage au TDD a largement augmenté ma motivation pour faire des tests.

+ Si t'as pas de suite de tests avant la fin, tu t'empêche tout seul de faire du refactoring et c'est plutôt dommage

Caletlog -> C'était du Java, c'était un jeu d'échec, je vois pas quand tu peux faire des tests unitaires qui va tester toute les combinaisons pour l'IA
Et savoir si le comportement de la pièce est normal ou pas.

• comment à la place de quand

Mais tu as bien des tests, puisque tu dis les faire à la fin...

Oué mais manuellement
Mais bon on est qu'en L2 on allait pas se lancer dans des tests unitaires alors qu'on savait à peine faire des objets

Ah d'accord, des tests manuels.

C'est soooo 2004

Non.
Les tests automatisés ne peuvent pas remplacer les tests manuels. Les TU te permettent de contrôler qu'une portion de code se déroule bien dans les cas normaux et anormaux auxquels tu as pensés, rien d'autre. Le second cas d'ailleurs ("le test ne doit pas fonctionner dans ces cas-là") est souvent oublié.

Les tests fonctionnels automatisés, quant à eux, te permettent d'assurer des scénarios standard variant peu ou pas.

Tu es obligé de réaliser des tests manuels à un moment ou un autre pour bien compléter le panel et être sûr de ta qualité. Ceux-ci peuvent facilement trouver des situations ou des configurations qui font sauter le programme.

En tant que dév' mobile, je pense notamment aux tests manuels multi-terminaux, qui permettent de trouver des couples version OS/terminaux (et on rajoute surcouche dans le cas d'Android) qui ne se comportent pas normalement, ou qui ont des soucis de mémoire, ou qui font l'inverse de ce qui est écrit dans la documentation, ou...

Les tests auto servent pour garantir des situations, aider au refactoring et prévenir les régressions.

Bref : les tests automatisés, c'est bien, mais se reposer intégralement dessus est une mauvaise idée

Je vois pas ce que vous entendez par test automatisé...

Dans un jeu de plateforme 2D par exemple comment on peut faire autrement que tester tout manuellement ?

Bunyan > Je sais bien, je disais ça sur le ton de la plaisanterie.

Mais y'a des milieux où, si je devais choisir, je préférerais ne prendre que des tests automatisés, qu'uniquement des tests manuels.
Quand on fait du dev web avec un site non statique ou, grand dieu, une SPA en js, ou même simplement dès qu'une DB intervient, on peut pas se permettre de passer 3 heures sur des tests manuels. Déjà, dans des projets comme ça on a rarement le temps, mais en plus c'est complètement contre-productif : comment on teste chaque formulaire, chaque input, chaque étape d'un modèle CRUD, les fonctionnalités JS, ... à la main ? Si on doit le faire une fois, okay, mais déjà à partir de deux fois c'est insoutenable. Sans les stubs, les mocks, les seeds, ... pour tester dans un environnement clos et pas polluer les DBs, tester une application web est une perte de temps incroyable. Alors qu'à côté niveau interaction web, avec des outils comme Selenium on a moyen de prévoir un nombre hallucinant de cas en très peu de temps.

Oui, il faut des tests manuels, mais pour moi ils ont leur place à la fin du projet, ou lors de 'points de passages' importants. En soit, ils sont bien trop inefficaces pour valoir le coup dans la phase de développement de pas mal de projets, je trouve.

Erf... désolé, j'ai pas saisie la plaisanterie :/

De mon côté, faisant des livraisons toute les deux semaines, nous tentons de réaliser une passe au moins superficielle tout les mois, histoire de vérifier certaines UI, certains comportement, de nouvelles implémentations... en plus des divers TU et tests fonctionnels, histoire de découvrir des trucs z'et des machins et compléter la couverture.

@hexabeast : la définition de tests automatisés est de réaliser des tests à divers niveaux pour s'assurer qu'une partie/section/zone réagit correction en cas de données correctes, incorrectes et totalement WTF.

Un test unitaire est un test couvrant une petite partie du code. Il faut que celui-ci soit bien découpé et faiblement couplé pour que le code soit réellement testable. Un test unitaire sert à vérifier que la portion de code se comporte bien avec les bonnes données, des données erronées et du n'importe quoi.

Un test fonctionnel est un test se réalisant au niveau de l'interface, singeant des entrées utilisateur et vérifiant que le comportement observé correspond à l'attendu.

Tu trouveras aussi le nom "test d'acceptation" pour les tests fonctionnels, et c'est l'une des pires inventions de l'histoire de l'humanité

"Ca dépend", c'est la seule réponse valable je pense.

Ayant toujours été sur du winforms ou du windowbuilder (en java), quand j'ai enfin pu me mettre au WPF au boulot, j'ai bloqué pendant deux heures sur les animations tellement c'était rigolo .

Et avant ça, on m'a fait faire de la "mise à jour" de code VBA de macros Excel datant de 1995... Bah j'me suis moins marré .