Reprise du message précédent :

Du coup PC, écran etc. j'ai plein d'appareil qui en ont. Si y'a pas de quoi s'alarmer ça va, mais il est déjà assez cher cet appart, donc ça m'ennuie de prendre un truc avec l’électricité moyenne (c'est une location). Surtout si je me prends des châtaignes H24 ou que le disjoncteur saute.
Merci pour ta réponse en tout cas.

Un grand classique du conspirationnisme : s'il n'y a pas de preuve de complot, c'est qu'il y en a un.
 
Elle sort un truc comme ça sur les clauses de confidentialité quand un ex. employé lui dit qu'il n'en a jamais signé, elle répond que c'est typiquement le genre de chose qu'il dirait s'il en avait signé une.
 

 
Achète un onduleur sinon  

C'est ce que je pensais faire si jamais je prenais l'appart. Sauf si on me dit que la mise à la terre en vrai, osef vu que [insérer une explication].

Tests unitaires : testez-vous les méthodes private ou juste les méthodes publiques ?
Pour ma part, je ne teste que les publiques, puisqu'elles font appel aux privates. Je trouve donc inutile de tester ces dernières 2 fois. Mais il parait que c'est pas bien.
 
Vous avez 2 heures.

Un seul critère pour juger de la qualité d'un appart : s'il est fibré, ou à défaut, s'il est éligible au VDSL2.
Tout autre critère est irrelevant  

edit: ne pas négliger la 4G, ça peut être utile pour du tethering en cas de panne internet.

Comment tu testes une méthode privée sans changer sa visibilité?

Par réflexion

 
C’est mon premier critère. Fibre. Ensuite parking privé.  
Donc le premier c’est ok.

Le tests unitaires c'est pour de petites unités non-triviales, donc oui j'aurais tendances à tester les méthodes non publiques à ce niveau là, si elles sont pas triviales, sauf si il y a des méthodes publiques testées qui impliquent clairement l'intégralité de la méthode privée.

En Python la visibilité est une convention, en Rust les tests unitaires (pas d'integ) sont dans le module qu'ils testent, et ont visibilité complète (tout élément d'un module a visibilité complète sur le module et ses ancêtres quelle que soit la visibilité déclarée).

 
friend of course  

Oui mais Harko il fait toujours du Java, non?
 

Cf. plus haut.

Je ne teste jamais les méthodes privées. Si elles méritent d'être testées elles méritent d'être dans leur propre module d'où elles sont accessibles, et je teste ce module tout seul. Rendre accessible une méthode au test juste pour pouvoir la tester directement c'est une hérésie.

Merci pour vos réponses
(enfin, merci Masklinn surtout )

Bah en Java, je vois mal comment faire autrement à part tout mettre en public bien salement

C'est justement le cas, les méthodes private sont très concises et ne font qu'une seule chose. Du coup, leur couverture par les méthodes appelantes approche ou est égale à 100%.

que D.ieu me préserve du C++

Oui

 
et  
 

 
C'est toujours très élégant  

 
Je ne teste que les méthode publiques. C'est elles qui définissent le contrat que remplit la classe, les TU valident ce contrat.
Si il y a des méthode privées non triviales a tester, il faut se demander si elles ne méritent pas d'être dans un autre objet. Il y a une école de pensée qui dit que toutes le méthodes devraient être publiques, toujours. J'irais pas jusque là, mais je considère une classe avec beaucoup de code privé un code smell.

https://twitter.com/fukawi2/status/1043089927657811968

Hahaha, je sens de nouvelles emmerdes arriver encore plus vite (je ne connais pas ce monsieur qui Tweet)

edit: et je relance de 2 https://twitter.com/fabiorauber/sta [...] 3389062145

Default et @VisibleForTesting.

Ça reste sale mais moins pire que tester une méthode par réflexion.

On n'utilise pas Guava

Euh... source ?
 
(Pour le reste je suis d'accord !)

https://github.com/google/guava/blo [...] sting.java
 
Tu devrais pouvoir copier ça quelque part dans une bibliothèque commons/util maison, non?

Sinon Netflix qui m'envoie un email

l'école de pensée gelatine_velue

M'ouahahaha 2j pour en arriver à ça

[img][/img]

Dans le genre fail ça se pose là

 
idem...ça sent l'A/B test configuré par un stagiaire non encadré

Le souci est réglé, je viens de faire un long mail à mon N+1 avec capture d'écran lui montrant que les méthodes private (qui ne dépassent pas 10 lignes, voire sont des one-liners pour beaucoup) sont couvertes à 100 % et que c'est inutile et une perte de temps (et donc d'argent, l'argument qui fait toujours mouche) de les tester

pareil

 
Pareil

Il me semble que Netflix engage que des gens expérimentés, pas de stagiaires ou juniors.

 
le truc c'est que les outils IT ont tellement vulgarisé ça que c'est dans les mains de n'importe qui

 
 
Ex: http://wiki.c2.com/?MethodsShouldBePublic

deux jours de chasses aux fuites mémoire

Mais bon, ça a servi a quelque chose, l'application à bien maigri, et j'ai mieux compris la gestion de la mémoire par swift

T'avais un cycle dans l'appli?

 
+1

c'est les features que j'ai développé
 
Du coup je me retrouve dans une situation sympa, on voit mes features, mais les mecs qui se sont fait chier à trouver comment on compile la centaine de rpm, dans quel ordre et comment se passer du code privé, personne voit leur boulot

1. Héhé À toi la gloire !
2. C'est le boulot de mainteneur, c'est un travail de l'ombre…

Comme souvent, faut trouver les modifs qui sont pas « ouf » en terme de code ont un effet « wahou » important. Je pense que c'est ça mon boulot que je sais bien faire

Bon par contre parfois ya des fois où tu tombes dans un trou noir sans le savoir (la problématique du O_DIRECT avec ZFS )

 
Avec une inner class static ?

@nray, on ouvre un poste de devOps ici. T'as l'air d'avoir le profil vu ton travail recent.