J'ai le programme suivant à Pharo: 2 classes de Yacht et YachtRental, Test Class et YachtRental test. Je dois mettre en œuvre ce qui suit: le 4ème jour, le client obtient une remise = 10% sur le tarif journalier. Voici mon code:
Je dois implémenter ce qui suit: le 4ème jour, le client bénéficie d'une remise = 10% sur le tarif journalier. Voici mon code:
| yachtRental myCruise |
yachtRental := YachtRental new.
myCruise := Yacht cruise.
self assert: (yachtRental priceFor: myCruise days: 4) = 890
Fondamentalement, je dois être en mesure d'implémenter la réduction de 10% ici, cependant il y a un message «Utiliser assert: equals: produit un meilleur contexte en cas d'échec de la règle », pourriez-vous s'il vous plaît m'aider à expliquer ce qui ne va pas.
3 Réponses :
assert: prend un booléen, alors que assert: equals: prend deux expressions. Et, assert: ne sait pas ce que vous testez, mais assert: equals: sait que vous testez pour que deux choses soient égales.
En cas d'échec de votre test, assert: ne peut pas imprimer un message d'échec significatif car toutes les informations auxquelles il a accès sont fausses , donc tout ce qu'il peut imprimer est " Je m'attendais à ce que quelque chose soit vrai, mais ce n'était pas le cas. "
assert: equals: a accès aux valeurs des deux expressions et peut donc imprimer quelque chose comme "Je m'attendais à ce que foo soit égal à bar ".
Étant donné que les bons messages d'échec sont l'un des aspects les plus importants d'une bibliothèque de test, les auteurs de la bibliothèque de test vous guident pour utiliser les assertions les plus expressives de leur bibliothèque au lieu d'un générique "est-ce vrai?"
[Note: j'ignore la réflexion ici. Les deux méthodes pourraient, bien entendu, inspecter de manière réfléchie le code source du test.]
Je pense que la question porte davantage sur le codage de yachtRental priceFor: myCruise days: 4 que sur le problème plus subtil de #assert: par rapport à #assert: equal: (ce que, BTW, Jög a expliqué si clairement.)
Assez intéressant, le codage de #priceFor: days: , apparemment simple, en soulève des doutes sur le test et la spécification de la remise.
La remise doit-elle être appliquée à chaque jour de la période de location lorsque la période est de 4 jours ou plus? Ou devrait-il être appliqué aux jours 4, 5, etc.?
Dans le premier cas, la logique serait
rate = 890 / 3.9 = 228.205128205128
et dans le second
rate * (3 + 0.9) = 890
Mathématiquement, la première politique de remise totaliserait un prix de
rate * 3 + (rate * 0.9 * (4 - 3)) = 890
qui doit être égal (jeu de mots) 890 . Cela signifie que le rate devrait satisfaire
rate = 890 / (4 * 0.9) = 247.222222222222
, ce qui est plutôt drôle, n'est-ce pas?
Et qu'en est-il la deuxième politique. Dans ce cas, nous aurions
rate * 4 * 0.9
ou
priceFor: aYacht days: anInteger
| rate |
rate := aYacht dailyRate.
^anInteger < 4
ifTrue: [rate * anInteger.]
ifFalse: [rate * 3 + (rate * 0.9 * (anInteger - 3))]
donc
priceFor: aYacht days: anInteger | price | price := aYacht dailyRate * anInteger. anInteger >= 4 ifTrue: [price := price * 0.9]. ^price
qui, encore une fois, ne ressemble pas à un tarif de location journalier.
Donc, ma conclusion est que le test doit être erroné ou que la politique de réduction n'est pas suffisamment spécifiée.
Le système suggère que vous souhaitiez peut-être utiliser
auto affirmation: (yachtRental priceFor: myCruise onDay: 4)
égale: 890
au lieu de simplement #assert:
mais cela n'a pas vraiment d'importance.
Ce que vous avez fait est très bien.
Vous voudrez probablement demander au vendeur. Ce message a été ajouté à la langue par les responsables pour une raison quelconque. github.com/pharo-project/pharo/issues (mais on dirait qu'ils veulent vous devez utiliser la méthode / l'opérateur
: equalsplutôt que l'opérateur=.)vous devez avoir une méthode qui échoue pour percevoir la différence. Je vous suggère de programmer la mauvaise remise et d'observer la différence entre l'utilisation d'assert: vs assert: equals: dans le rapport d'erreur.