Ce que je dis, c'est qu'en entretien, si le sujet est abordé par le recruteur, il suffise que je dise que je ne soumets pas mon code à des tests unitaires pour que la plupart d'entre eux ai un à-priori négatif à mon sujet, comme si cet état de fait était limite constitutif d'une faute professionnelle et impliquait une opposition inconditionnelle de ma part à leur mise en œuvre quelle que soit la situation.
Tu comprends bien qu'on est plus trop ici dans l'optique "que faisiez vous avant ?" mais plutôt "qu'êtes vous prêt à faire avec nous ?" et que si tu insistes en disant que tu as pris l'habitude de bosser sans tests unitaires, si l'autre en face n'est pas né de la dernière pluie, va interpréter ça comme "ouais alors lui, je pense qu'il aime pas les tests unitaires, il a des années de stratégie d'évitement (pas forcément au sens négatif du terme) pour les utiliser, ça va pas l'faire avec nous car on bosse en équipe avec parfois des stagiaires qui mettent les mains dans le code, ou bien seulement des gens qui veulent optimiser une routine bas niveau la veille de la mise en prod' et paf le chien"
Pour ma part, je considère que pour un code donnée, il faut toujours assumer que
- on est pas le seul à bosser dessus (même si on est vraiment seul à un moment donné)
- l'autre n'aura pas forcément notre connaissance du code
- l'autre, c'est peut-être nous-même dans quelques mois/années
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Guillaume Denry (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 4.
Tu comprends bien qu'on est plus trop ici dans l'optique "que faisiez vous avant ?" mais plutôt "qu'êtes vous prêt à faire avec nous ?" et que si tu insistes en disant que tu as pris l'habitude de bosser sans tests unitaires, si l'autre en face n'est pas né de la dernière pluie, va interpréter ça comme "ouais alors lui, je pense qu'il aime pas les tests unitaires, il a des années de stratégie d'évitement (pas forcément au sens négatif du terme) pour les utiliser, ça va pas l'faire avec nous car on bosse en équipe avec parfois des stagiaires qui mettent les mains dans le code, ou bien seulement des gens qui veulent optimiser une routine bas niveau la veille de la mise en prod' et paf le chien"
Pour ma part, je considère que pour un code donnée, il faut toujours assumer que
- on est pas le seul à bosser dessus (même si on est vraiment seul à un moment donné)
- l'autre n'aura pas forcément notre connaissance du code
- l'autre, c'est peut-être nous-même dans quelques mois/années