Reprise du message précédent :

Oui mais si la classe est dérivée (et c'est le but si la méthode est protected), la méthode privée appelée pourra être celle de la classe dérivée. Donc il est possible de mettre à jour un bug de la classe mère en testant la classe fille, et c'est trop tard.

 
Question de point de vue, on peut aussi appeler ça un bug de la classe fille, qui utilise une méthode en se fourvoyant sur son comportement attendu.

T'as pas à te fourvoyer, on te passe une API (en l'occurence les méthodes de la classe mère), celle-ci doit être testée.

dear customer,  
 
you're retarded.
 
best regards,
 
-uriel

Les deux se défendent amha. Pour moi si tu découvres un bug dans les tests de la classe fille c'est que t'avais merdé dans ceux de la mère.

Hello, j'ai une petite question rapide pour les flasheux :
 
Qu'est-ce qui peut alourdir une première image ? J'ai une première image qui devrait peser 64 ko et qui sert de loader, mais comme il y a des choses qui se chargement en première image j'en arrive à 512 Ko (pour 1.8 Mo d'animation). Ca fait beaucoup... Et jsais pas ce qui alourdit à ce point cette première image, et comment l'alléger au maximum (histoire que mon animation de loading n'apparaisse pas comme là au tiers du chargement)

tu sais pas programmer et on te dit rien donc plz stfu

putain linux
je veux ouvrir un SFTP où les gens peuvent naviguer que dans leur répertoire perso, est-ce que vous avez une doc là-dessus ? Je vois que des trucs de chroot qui ne répondent absolument pas au problème.

 
http://www.minstrel.org.uk/papers/sftp/builtin/

subsystem request failed on channel 0

edit: en fait ça marche, boulette

 
Je sais.
 

 
C'est bien l'idée : arriver en disant : "j'ai jamais fait, je me suis renseigné, ça m'intéresse, et je voudrais en faire".
 

 
  j'vais regarder le bouquin. Merci.

Pas forcément utilisée, mais surchargée
 
T'as 2 cas de figures pour protected :

• Permettre à une classe fille de changer le comportement d'une classe mère en surchargeant une méthode
• Offrir à une classe fille des fonctionnalités non accessibles publiquement

Dans le premier cas on testera juste l'API publique, dans le deuxième cas pourquoi pas effectivement tester les protected Discuss

Sauf que le mec qui écrit la classe fille est pas forcément celui qui a développé la classe mère. Donc le mec qui développe la fille s'attend à ce que le développeur de la mère ai testé ses méthodes protected

Bin vu comment ça discute sur le sujet, vaut mieux pas trop qu'il s'y attende, non

Je suis d'accord c'est le deuxième cas qui justifie de tester les protected. Mais comme il y a qu'un seul mot clé si tu veux faire le premier cas tu autorises aussi le second. Donc tu dois tester.

Bah non. Si le bug est dans une méthode protected et que tu testes pas les protected, tu peux ne jamais avoir ce cas qui survient dans les méthodes de la classe mère utilisant la méthode protected, soit parce que c'est une UB soit parce que le domaine de def des méthodes de la classe mère n'étend pas le domaine d'utilisation de la méthode protected jusque là.

Et de toute façon même si tu veux faire que le premier, faut tester parce que tu dois bien checker que ta classe mère se vautre pas quand ton hook est utilisé.

en fait non, parce que je veux mettre un umask à 022
 
mais j'ai http://forums.debian.net/viewtopic.php?f=5&t=42818
 
et pour mettre le umask, je trouve http://www.larrykagan.com/blog/view/SFTP-umask
 
j'ai une question par rapport à ta page, il parle de mettre une variable dans /etc/default/login, mais ce fichier n'existe pas chez moi, est-ce que simplement le rajouter suffit à ce qu'il soit lu ?

Même le deuxième cas me parait un peu bancal, à moins qu'offrir ces fonctionnalités soit la finalité de la classe en question. Auquel cas ça a de bonnes chances d'être aussi bien en public.
 
Bref, je vois pas des masses de raisons d'avoir des méthodes protected qui ne soient pas utilisées dans la classe elle-même. Auquel cas des tests unitaires sur les méthodes publiques de la classe devraient suffire à couvrir les méthodes protected.

il n'y est pas par défaut ? le param par défaut sur les debian (et dérivés) c'est justement 022.

edit : testé ici, c'est 022 par défaut sur un put en sftp
edit 2 : et le fichier c'est /etc/login.defs

Tes tests ne sont pas unitaire alors.

Je teste pas plus d'une méthode publique à la fois.

 
Explain

bizarre, moi mon fichier il est en -rw------- après le put.

stop talking nonsense.
all of you.

merci

Tu test une méthode pour tester le comportement d'une autre méthode, donc c'est pas unitaire. Généralement tu mock ces appels. Bon si la méthode fait rien, pas la peine de se casser le cul non plus...

Sinon, il fait beau et chaud en Martinique

 
c'est pas les droits du fichier que tu envoies justement ?

Mais ça dépend toujours où tu places l'unité. J'ai lu Growing Object-Oriented Software, Guided by Tests (très intéressant ), ils placent l'unité au niveau de la fonctionnalité.
 
Ainsi une classe n'offre pas des méthodes, mais des fonctionnalités. Un test unitaire pourra potentiellement appeler plusieurs méthodes, et essayer plusieurs assertions.
 
Ils placent au-dessus de ça des tests d'acceptance, qui vont valider des fonctionnalités cette fois-ci au niveau global : un test d'acceptance va par exemple déployer et configurer le soft, lancer des actions au niveau de la GUI, et vérifier ce qui se passe.
 
J'ai trouvé l'idée plutôt intéressante, j'ai implémenté quelques-uns de ces principes. Et en relisant les test unitaires quelques semaines après, je les ai trouvés plus lisibles et clairs : ils deviennent presque une documentation à part entière sur comment utiliser l'objet, et quels sont ses comportements.

C'est plus un test unitaire s'il fait ça. Le but d'un test unitaire c'est de checker le contrat d'une unité de code, c'est à dire du plus petit ensemble de code testable possible, c'est à dire une fonction, une méthode ou une macro (dans la majorité des langages).

Pas necessairement, sauf si c'est critique, sinon tu testes les méthodes qui appellent cette unité en admettant qu'elle soit la plus straightforward possible, et que tu sois exhaustif dans les tests dépendants. Mais bon à ce compte là c'est plus du test unitaire puisque tu ne testes plus une unité mais un ensemble de code.

Bon, ils doivent être à la ramasse en profils techniques, parce qu'il a pas fallu 2h pour qu'ils rappellent, aors que j'ai 0 Xp de chef de projet, ni d'agilité.
 
RdV la semaine prochaine, ca va être tendu..

Meu non. Prépare ton entretien ce WE en formalisant tes connaissances (va probablement falloir répondre à un entretien technique à la con avec des questions du style "qu'est-ce que le polymorphisme ?" ), faut que tu saches bien résumer ce que t'as fait et pis vala.

 
euh.. ouais, enfin, j'ai un peu passé l'âge d'avoir à répondre à ces questions, mais bon..
 
Généralement, les gens sont plus intéressés sur le "pourquoi vous voulez bouger?" que pas mes compétences techniques.
En l'occurence, faudra que j'argumente sur le fait que même si j'ai pas d'XP dans certains domaines du poste, je suis quand même intéressant pour eux, et que j'ai envie de m'investir dans le truc.
 
Pis l'entretien se fera sans doute au resto.
 

...et après tu vas te plaindre que t'as pas le physique au basket.

 
hého. Au moins, je suis là tous les lundis.
 
Normalement, lundi prochain, y'a un collègue qui vient. Il doit faire un bon 1m90, et il a fait le sparring partner au centre de formation de l'Elan Béarnais du temps des Piétrus Brothers et de Boris Diaw. Bon, il a pas la condition, mais je pense qu'il va quand même nous mettre minables.

 
Tu parles, je suis venu que 3 fois et la seconde t'étais pas là avec une sombre excuse de voiture cassée.
 

 
Ah ben je risque de prendre moins de rebonds, d'un coup.

Sauf qu'il y a souvent le cas où le résultat d'une méthode va dépendre d'autres méthodes. Genre exemple que j'ai lu ailleurs :
 
Tu prends une class Stack, avec des méthodes push & pop. Tu peux pas tester pop toute seule, sans avoir push d'abord. Un test ressemblera à ça :  

Là en voulant tester push, j'ai aussi fait appel à pop. Les deux sont liées Du coup là même le nom du test est foireux, faudrait renommer en testStackStoresAndReleasesObject par exemple.
 
Ensuite on continue avec une 2ème fonctionnalité, genre si on push plusieurs truc, on s'assure qu'on pop le dernier :

 
Les fonctionnalités de la classe sont ainsi clairement montrées.

 
Si on est assez nombreux, on fera 4 équipes, et tu joueras qu'une fois contre lui...
 

 
Ou mieux, il sera dans mon équipe!

faudrait un peu arrêter d'enculer les mouches, non ?