Reprise du message précédent :

... Sauf quand le rappel est envoyé à la même mauvaise adresse que l'original.

Le tiers monde informatique qu'est la belgique (et la france aussi)

Mais j'ai pas bougé entre temps, j'ai aucune difficulté à croire que du courrier se paume dans les déménagements, même avec la plus longue période de redirection de courrier que tu peux mettre.

Une paire d'erreurs c'est pas des masses, ça s'aligne facilement.

J'ai reçu l'original, j'étais persuadé de l'avoir fait, en fait non .... J'ai reçu le rappel avec les 10% en cadeau, j'ai réglé direct  

dites quand vous faites des TU, vous faites plutot :  
 

def test_method_good:
    assert method(1) == "Good"
    assert method(99) == "Good"
 
def test_method_bad:
    assert method(-1) == "Bad"
    assert method("foot" ) == "Bad"

 
ou plutot
 

def test_method_ok_min_bound:
    assert method(1) == "Good"
 
def test_method_ok_max_bound:
    assert method(99) == "Good"
 
def test_method_bad_lower_than_lowerbound:
    assert method(-1) == "Bad"
 
def test_method_bad_higher_than_upperbound:
    assert method(9999) == "Bad"
 
def test_method_bad_type:
    assert method("foot" ) == "Bad"

def test_method_good:
    assert method(1) == "Good"
    assert method(99) == "Good"
 
def test_method_bad:
    assert method(-1) == "Bad"
    assert method("foot" ) == "Bad"

def test_method_ok_min_bound:
    assert method(1) == "Good"
 
def test_method_ok_max_bound:
    assert method(99) == "Good"
 
def test_method_bad_lower_than_lowerbound:
    assert method(-1) == "Bad"
 
def test_method_bad_higher_than_upperbound:
    assert method(9999) == "Bad"
 
def test_method_bad_type:
    assert method("foot" ) == "Bad"

Dépend des jours, de la complexité des APIs, du nombre de trucs à tester, etc..

Pour des appels triviaux comme ton exemple, je mettrais tout dans le même test, avec un message d'assertion pour expliquer la logique.

Alternativement (enfin pas vraiment alternatif vu que la logique est la même mais mieux intégré à l'outillage) vu que t'es apparemment sous pytest, tests paramétriques.

def test_method_good: 
assert method(1) == "Good" 
assert method(99) == "Good" 
 
def test_method_bad: 
assert method(-1) == "Bad" 
assert method("foot" ) == "Bad"

def test_method_ok_min_bound: 
assert method(1) == "Good" 
 
def test_method_ok_max_bound: 
assert method(99) == "Good" 
 
def test_method_bad_lower_than_lowerbound: 
assert method(-1) == "Bad" 
 
def test_method_bad_higher_than_upperbound: 
assert method(9999) == "Bad" 
 
def test_method_bad_type: 
assert method("foot" ) == "Bad"

2. Je déteste les tests avec assertions multiples, tu crois que t'as fixé le bug et t'as l'assertion suivante qui t'explose à la figure

 
 
oui j'ai vu ça, mais ça suppose que le corps de la méthode de test est toujours le même, ce qui n'est pas mon cas.
Je me fais un outil pour aller récupérer les questions stackoverflow selon certaines conditions.
j'ai donc une méthode qui gère l'appelle à la méthode "questions" https://api.stackexchange.com/docs/questions qui a les paramètres qu'on voit en bas dans le "try it", et qui doit me fabriquer un objet "params" à passer à l'appel de méthode.
 
donc pour chaque je dois me taper des tests genre pas d'input (vérifier que je passe le bon default), un input acceptable, un input pas acceptable, etc... Du coup j'ai des cas qui renvoient des exceptions, d'autres pas, et surtout selon les cas je m'attends (ou pas) à trouver des valeurs dans params.

Fallait pas donner un exemple où c'est le cas alors

Si c'est juste paramètres et sortie ça passe, tu peux avoir un triplet de (paramètres, sortie, exception), ou même (paramètres, sortie | exception), avec un test de type qui dispatch entre les deux. Avec un paramètre supplémentaire qui est un message d'assertion / une explication par souci de clarté.

Genre là je viens d'écrire ça:

for i in 0..10 {
    let result = Value::listen(&"HO".repeat(i));
    if i % 2 == 0 {
        assert!(matches!(result, Ok(_)));
    } else {
        assert!(matches!(result, Err(ListeningError::OddNibbles(_))));
    }
}

Bof dans tout test pas trivial tu vas probablement avoir plusieurs étapes, avec chacune sa ou ses assertions.

1/ ça m'a fait réfléchir, et je me dis que j'ai pas forcément de raison de garder les defaults de l'api (genre pagesize=30) dans mon code, puisque si je passe rien, j'aurais ce default quand meme
2/ tu vois ça où dans pytest ?
 

bon ben vendu :  
 

@pytest.mark.parametrize(
        "field, value, result, message",
        [
            ("filter", None, None, None),
            ("filter", "TEST", "TEST", None),
            ("page", 30, 30, None),
            ("page", -1, ValueError, r"The page number provided -1 is not valid" ),
        ],
    )
    def test_all_fields(self, field, value, result, message):
        """Tests build_questions_params for good and bad inputs."""
        if isinstance(result, type) and issubclass(result, Exception):
            with pytest.raises(result, match=message):
                so_importer.build_questions_params(**{field: value})
        else:
            params = so_importer.build_questions_params(**{field: value})
            assert params.get(field) == result

 
pour rajouter des tests j'ai qu'à rajouter des tuples dans l'array. Bien plus rapide

Ptain, l'extension Top Gun:Maverick pour Flight Sim, ça envoie du lourd ! On s'y croirait vraiment

curieusement j'imagine un paisible quartier en Gironde, dont la quiétude est troublée par un "HIGHHHHHHHHHWAAAAAAAAY TOOOOOOO THE DANGERZONE" qui s'échappe en boucle d'une des maisons

C’est une méthode d’utilisation
 
La paramétrisation de tests te donne des valeurs, derrière t’en fais ce que tu veux, c’est ça qui est cool, tant que tu peux réifier un concept tu peux trouver un moyen de le mettre dans ta table (après faut pas non plus abuser, quand tu dépasses la demi douzaine de paramètres ça commence à faire beaucoup).

Sinon quelqu’un a un bon scheme de versioning pour une lib basées sur des données descriptives, mais dont l’api peut évoluer?
 
Genre une lib de timezones ou unicode, les données vont informer l’api mais elles vont aussi évoluer indépendamment, donc une release peut faire évoluer l’api, ou les données, ou les deux, potentiellement en parallèle (on peut imaginer deux releases pour la même maj de données, une qui touche pas l’api et l’autre si, qui resteraient des branches parallèles).

C'est un truc d'ayatollah ça, y'a un million de raisons qui font que l'assertion peut et doit être multiple, sauf à forger des assets de réponse qui vont tester de multiples choses, mais ce sont d'autant plus de trucs à maintenir.
 

J'utilise ça très très souvent en Java via JUnit tu as tout un tas de sources de parameterized tests, CSV, fonction qui renvoie des liste de paramètres, JSON, etc, c'est très utile, et ça doit très probablement exister dans panoplie de langages et frameworks  

 
j'avais pas compris comment utiliser une exception, mais c'est bon là. Du coup ça a bien compressé mes tests
Next : jouer avec la pagination sans me foutre dedans (l'API SO est bizarrement documentée, y'a des trucs très complets sur des choses évidentes, et ils décrivent en 3 lignes des trucs compliqués qui auraient mérité un exemple), et persister ça proprement dans une base sqlite avec gestion du "récupérer les posts depuis le dernier lancement du script"
Ensuite, go nltk
 

 
j'avais jamais utilisé, c'est bien pratique

bien vu, je me suis mis la musique pendant l'alignement et le décollage

Je suis d’humeur monorepo perso. J’essayerai pas de tracker 2 versions et la liste des versions compatibles entre elles.

Seigneur, donnez moi la confiance en soi du recruteur LinkedIn qui me propose un CDD de 18mois, de Product Manager, dans l’industrie automobile
 
 

Called it

Hello les gars  
 
J’suis un peu perdu et j’aurais besoin de vos lumières.
 
Les examens se sont bien passés et je vais être diplômé donc maintenant il faut réfléchir à la vie professionnelle. On a un projet d’expatriation au Canada pour 2023, il faut donc que je fasse un truc pendant un an.
 
Mais voilà le problème : je ne sais pas ce que je souhaite faire… du coup je ne sais pas comment me positionner par rapport aux différentes offres d’emploi.
 
Pendant ma formation, j’ai fait du développement 3D (C/C++, C# sur Unity), du client loud (Java, C++), du web (JavaScript, Python, Java), de la vision par ordinateur (C++, Python) et du dev Unix (C). Mais ça ne m’a pas permis de dégager une préférence parmi ces domaines du métier de développeur.
 
Je n’ai pas envie de faire un choix qui me fermerait des portes dans le futur.
 
Quel type de dev faites vous au quotidien ? Qu’est-ce qui vous plaît dedans ? Que me conseilleriez-vous ? Sur un plan intérêt, perspective à long terme et salaire ?
 
Bref, je suis un peu dans le brouillard…

C’est des projets différents gérés par des gens différents donc voilà.  
 
Puis je sais pas aussi bien d’un point de vue maintenance qu’utilisateur je trouve que c’est un peu chiant d’imposer des changements d’API pour avoir des maj de données, ou inversement de pas pouvoir toucher à l’API.
 
L’alternative ce serait de complètement séparer ces deux facettes en deux packages que tu utilises ensemble mais bon ça devient une grosse complication.

 
teste et tu verras bien . En web si tu as JS/ React|Vue| Angular, tu trouves du boulot un peu partout à des salaires correct. Chez plamcorp les plus gros salaires sont par contre des dev spécialisés ( genre C / Kernel)
 
je fais du back, j'aime le modèle mental à construire, les reflexions en multiples dimensions que ça amène ( que se passe t il si 1-10 clients font la même chose en même temps, ou des choses opposées).
Mais en vrai, j'ai surtout choisi une boite, la techno utilisée est accessoire : quelle alignement avec tes valeurs ( crypto, NFT, jeu d'argent, vente de medicaments, d'armes, ...)  quel équilibre vie pro/perso, quelles evolutions possibles, ...
 
 
 

 
je dirais que ça dépend du style de boite où tu veux bosser (ce dont tu n'as peut etre aucune idée).
Si tu vises des boites genre big tech, ça n'a aucune espèce d'importance : ce qui compte seront tes années d'XP, si tu as pris des fonctions de management ou pas, de leadership technique ou pas, et la capacité à passer les interviews qui sont très centrées pour data structures & algorithms, et system design. Dans ce cas tu te fermes aucune porte.
 
Dans les boites plus classiques, de ce que j'ai pu voir, tu prends une espèce de teinture avec les années. Les boites recrutant selon "on veut X, donc on cherche des gens qui ont déjà fait X", tu auras plus de mal à sortir de ton sillon. Si par ex tu fais du frontend, tu vas etre teinté "front", et tu trouveras facilement du job en front, mais ces boites seront en general réticentes à embaucher qqn qui a un profil back pour ce genre de role (hors pénurie aigue de profils).
Tu peux viser le fullstack. Je laisse les devs ici commenter, mais ça commence à faire une grosse surface de technos sur lesquelles te tenir à jour
 
tu es mobile géographiquement ?
 

J'étais un peu comme toi durant mes études, j'ai vu plein de trucs et tout me plaisait. Sauf qu'en plus j'arrivais pas à choisir entre système/réseaux et dev.

Du coup si tu veux une réponse rapide, ma solution a été de beaucoup bosser. Sinon pour le détail :

En gros pendant mes études j'ai fait un double cursus dev et réseau (j'ai pu valider qu'un diplôme), donc j'ai fait un bac+2 en réseaux/dev, un bac+4 en réseaux et la dernière année en alternance dev (dont 2 stages en réseau et un en "devops" ). Mon alternance, j'ai choisi de la faire dans une SSII pour pouvoir toucher à plein de projets et apprendre plein de trucs. En dehors du taff, je passais mes soirées à bosser sur plein de technos qui me plaisaient. Ca m'a permis de valider le fait que je préférais le dev.

Ensuite, et c'est mon conseil, j'ai choisi en fonction des entreprises plutôt que des technos que je maitrisais. J'avais un profil plutôt back-end PHP/Symfony et je me suis retrouvé à faire du Java et de l'AngularJS dans une boite qui m'attirais.  
J'ai vu que j'aimais pas du tout le Java. Dans cette boite j'ai pu découvrir React (et j'en fais toujours). A côté de ça, j'ai monté une auto entreprise qui m'a permis de commencer des projets directement en Node sans rien connaitre. J'ai fait deux gros projets, qui tournent encore très bien aujourd'hui. Avoir React et Node m'a donné la possibilité de postuler chez PlamCorps. Avec ce petit parcours, aujourd'hui je suis "fullstack". Ca m'a permis de m'orienté dans mes choix et de m'ouvrir quasi toutes les portes.
Aujourd'hui j'adore le web, y'en a partout et y'a plein de technos/projets intéressants. C'est pas parfait, parfois j'ai envie de faire autre chose, mais souvent je le fais sur mon temps perso quand les projets me tentent. Tu trouveras surement une boite qui te permettra de voir plein de technos ou tout du moins d'évoluer dans ce que tu préfères.

 
Bien joué !
 
Bonne chance pour ton début de carrière, j'ai pas de conseils à te donner

 
Vu le marché (et je crois pas que ça s'arrange avant un bon moment), je ne m’inquiéterais pas trop pour les "portes qui se ferment".  
 

 
Ce qui compte, c'est ce qui te plaît à TOI. Ce qui plait aux autres n'a pas grande importance. Tu es au début de ta carrière, fais ce qui te plaît et te prends pas à la tête à faire des calculs de carrière à 3 bandes.
 

 
Le salaire, c'est un peu le seul truc où effectivement tu peux chercher un compromis entre ce qui te plaît et ce qui te permet de gagner correctement ta vie.
 

C'est normal, puisque tu as plein de portes ouvertes à ton stade.

Fait ce qui te plait, si y'a rien qui te plait particulièrement regarde la où y'a le plus d'offre qui match salaire + avantages que tu souhaites avoir (remote, flexible, budget formation, congés, horaires, whatever)
 
Fais ton XP et tu verras, si vraiment ta passion c'est le jeux vidéo par exemple je pense que tu le saurais déjà et alors tu prendrais cette voie, c'est sûr que faire du dev low level en C après une carrière de 10 ans sur du PHP c'est peut être pas le jump le plus simple, mais je pense qu'en acceptant de perdre salaire/avantage tu sauras toujours rentabiliser ton XP et compétences transversales sur n'importe quel truc le jour où tu en as marre.

'tain hier j'ai fait du PHP où la concaténation de chaines se fait avec le point, et aujourd'hui je reprends le julia où la concaténation se fait avec l'étoile.
Je crois que je collectionne les perles

 
Félicitations, déjà
 
On a tous des envies différentes, je suis pas sûr qu'un conseil d'orientation soit ce que tu recherches.  
 
Pour ma part, j'adore résoudre des problèmes, du bugfix à l'algorithme qui tache et qui demande des mois de R&D. Du coup j'ai peu d'affinité pour un langage particulier, pour moi ce ne sont que des outils (même si j'ai mes préférences), et je suis du coup un "jack of all trades, master of none". Le front m'intéresse assez peu, même si j'en fais en ce moment (je kiffe dart/flutter, c'est très plaisant).
Certaines personnes se donnent à fond sur quelques langages et se spécialisent. D'autres se spécialisent sur des aspects du dev (front, back, DB, ops, ...). D'autres aiment bien se spécialiser dans une techno ou dans un sous-domaine particulier. D'autres surkiffent la gestion de projet. Etc, etc.
 
Bref, ce qu'il te faut là maintenant, c'est savoir comment faire pour savoir quoi faire. Introspection, voyage autour du monde, tenter plein de trucs... là aussi chacun a sa façon de faire, c'est toi qui doit trouver ce qui t'aide le mlieux à faire sortir tes envies et ta vision sur toi-même.
 
Je terminerais sur le fait que, dans le milieu de l'IT, la compétence à la base de tout, c'est de savoir apprendre. Si tu sais ça, alors les choix ne sont pas définitifs, et ne sont au contraire que des expériences qui t'apportent des points de vue et des angles de réflexions plus riches. Donc tu as assez peu de chance de "te tromper" : si à un moment ce que tu fais ne te plait pas, tu peux te réorienter assez facilement, avec une vision plus claire de ce que tu aimes faire.
 

 
O------+.*.+*.+*+.*.+*.+*+.*+.*+*.+*.*.+*+.*+.*+*.+*.*.+*+.*+.*+*.+*.*.+*+.*+.*+*.+*.+*+.*+.*.*------O
 
 
Tiens je t'offre ce collier de perles

cool, je vais pouvoir me le mettre dans le cul !

for i in 0..10 {
    let result = Value::listen(&"HO".repeat(i));
    if i % 2 == 0 {
        assert!(matches!(result, Ok(_)));
    } else {
        assert!(matches!(result, Err(ListeningError::OddNibbles(_))));
    }
}

Tu crois qu'on a pas vu que tu glissais subtilement que tu faisais du Rust ?

Par contre pour rebondir sur ce que disais masklinn sur les tests paramétriques, perso j'ai vraiment tendance à les réserver à des cas très simples. Encore plus pour les tests (vs le "code ordinaire" on va dire) je trouve que c'est important de comprendre facilement qu'est ce qui fait planter le test, et du coup c'est plus compliqué si t'as plein de "magie" dans le code du test, tout ça pour éviter quelques LOC. A choisir, je préfère souvent un peu de copier/coller dans les tests mais d'avoir des trucs très explicites (bon là dans ton exemple Jubi ça reste dans le suffisamment simple pour moi, mais si tu commençais à avoir plus de choses dans ton if/else (et notamment des cas particuliers en fonctions des champs), je pense que je préférerai une version non paramétrique.

@rokhlan : Le marché est tellement tendu que t'as pas trop de risque à mon avis, même si tu choisis un truc qui finalement te plaît pas trop de t'enfermer dans un truc. Si tu fais 2 ans de web mais que finalement tu préfères le mobile ou le pure back, tu devrais pouvoir assez facilement changer après (c'est sans doute plus compliqué si tu t'en rends compte après 15 ans par contre, notamment niveau salaire ). Du coup même conseil que les autres: choisi surtout en fonction de la boite, du secteur, etc...

 
bien joué.
ne te prends pas la tête avec des considérations "parasites", fait ce qui te plait le plus.

je vais te dire un truc qui va pas t'aider, je suis un peu d'accord avec jubi que les recruteurs pro adorent les gens qui sont déjà dans leur secteur.
genre le recruteur va vouloir embaucher des gens qui sont dans l'automibile ou dans le militaire.

Mais la réalité c'est que dans l'automobile tu peux être en train de faire le site web corporate (ou encore mieux, le site de PSA Banque), ou en train de programmer un ESP, ou des outils de simulation, ou des outils d'admin de machine. Donc du coup même dans un silo tu trouves un peu de tout.

Ensuite l'autre question c'est celle du réseau personnel, pour sortir des recruteurs pros. Est-ce que quelqu'un ici sur ce topic fait un truc qui te plait ? dans ce cas, contacte Plam en MP.

 
Ah, j'ai oublié de réagir là dessus : évidemment, une super idée d'aller vivre dans un autre pays et une super expérience, même si/quand ça rate ce que je ne vous souhaite évidemment pas.

C’est une nouveauté pour personne que je bricole avec si?
 

À noter que là pytest a un gros avantage (peut être d’autres aussi, mais en tout cas par rapport à des languages où tu dois faire ça à la bite et au couteau, genre rust si tu utilises pas des macros / trucs tiers): la paramétrisation est faite pendant la collection, ce qui la rend un peu plus coûteuse et moins flexible, mais veut dire que chaque ligne paramétrique est un test, et va être imprimée affiché comme tel.
 
Genre le truc de jubi, si la 3e occurrence échoue ça va dire que le test qui a échoué est un truc genre

et tu peux sélectionner ce test spécifique pour le faire tourner par la suite (et idem si tu utilises —lf & co ça va redémarrer à ce paramètre, pas au premier du test).
 
C’est vraiment vraiment bien foutu et pratique.

Merci à tous pour vos réponses    
 
Je vais prendre quelques temps pour réfléchir à tous vos conseils et surtout trouver ce qui me plaît.
 
Les modules que j’ai trouvé vraiment intéressant à l’école étaient “algorithmique avancée” et “vision par ordinateur et apprentissage”. Par contre ce dernier était tellement difficile

 
   
je peux mourir en paix
 
 
 

... sans compter le fameux test que tu rajoutes, qui colle pas exactement aux paramètres mais qui serait moche à part, alors tu rajoutes un paramètres, deux lignes dans la méthode utilitaire... 6 mois après tu recommences, et 6 mois après... et au final on a un test paramétrique avec une méthode utilitaire de 150 lignes, et autant de paramètres que de cas de test...

Putain je glande rien ce matin, j'ai une méga flemme, j'ai des trucs à faire mais je n'arrive tellement pas à me lancer, wtf  

Non, je pensais même que tu en faisais en daily a la cogip  
 

C'est pareil dans le Java world oui