Quelle est la différence entre expect(something).toBe(true)
, expect(something).toBeTruthy()
et expect(something).toBeTrue()
?
Notez que toBeTrue()
s'agit d'un matcher personnalisé introduit jasmine-matchers
parmi d'autres matchers utiles et pratiques comme toHaveMethod()
ou toBeArrayOfStrings()
.
La question est censée être générique, mais, à titre d'exemple réel, je teste qu'un élément est affiché dans protractor
. Quel matcher dois-je utiliser dans ce cas?
expect(elm.isDisplayed()).toBe(true);
expect(elm.isDisplayed()).toBeTruthy();
expect(elm.isDisplayed()).toBeTrue();
.toBe(true)
==.toBeTrue()
. toBeTruthy () peut être vrai non seulement sur vrai , mais sur 123 , "dfgdfg", [1, 2, 3], etc ...if(x==true)
sont fondamentalement véridiques, alors queif(x===true)
sont vrais vrais.toBeTruthy
si vous n'êtes pas sûr du type, c'est le même que,== true
alors que je soupçonne que.toBe(true)
c'est le même que=== true
Mind you, c'est un peu exagéré d'appeler une fonction à tester pour vrai. Un conseil ,. Oubliez==
et!=
existe en Javascript et ne l'utilisez plus jamais. La vérité n'est pas nécessaire et un piège pour les débutants. Utilisez===
et à la!==
place.eslint
signalé si==
ou!=
sont utilisés suggérant de le changer en===
et!==
.Réponses:
Ce que je fais quand je me demande quelque chose comme la question posée ici, c'est d'aller à la source.
être()
expect().toBe()
est défini comme:Il effectue son test avec
===
ce qui signifie que lorsqu'il est utilisé commeexpect(foo).toBe(true)
, il ne passera que s'il afoo
réellement la valeurtrue
. Des valeurs véridiques ne feront pas passer le test.toBeTruthy ()
expect().toBeTruthy()
est défini comme:Coercition de type
Une valeur est vraie si la contrainte de cette valeur sur un booléen donne la valeur
true
. L'opération!!
teste la véracité en contraignant la valeur transmiseexpect
à un booléen. Notez que contrairement à ce que la réponse actuellement acceptée implique ,== true
n'est pas un test correct pour la véracité. Vous aurez des choses amusantes commeAlors qu'en utilisant les
!!
rendements:(Oui, vide ou non, un tableau est la vérité.)
pour être vrai()
expect().toBeTrue()
fait partie de Jasmine-Matchers (qui est enregistré sur npm commejasmine-expect
après un projet ultérieur enregistré enjasmine-matchers
premier).expect().toBeTrue()
est défini comme:La différence avec
expect().toBeTrue()
etexpect().toBe(true)
est queexpect().toBeTrue()
teste s'il s'agit d'unBoolean
objet.expect(new Boolean(true)).toBe(true)
échouerait alorsexpect(new Boolean(true)).toBeTrue()
que passerait. C'est à cause de cette drôle de chose:Au moins c'est la vérité:
Quel est le mieux adapté pour une utilisation avec
elem.isDisplayed()
?En fin de compte, Protractor transmet cette demande à Selenium. La documentation indique que la valeur produite par
.isDisplayed()
est une promesse qui se résout en aboolean
. Je le prendrais au pied de la lettre et utiliserais.toBeTrue()
ou.toBe(true)
. Si je trouve un cas où l'implémentation renvoie des valeurs véridiques / fausses, je déposerais un rapport de bogue.la source
En javascript, il y a des vérités et des vérités. Quand quelque chose est vrai, c'est évidemment vrai ou faux. Quand quelque chose est véridique, il peut ou non être un booléen, mais la valeur «cast» de est un booléen.
Exemples.
Cela peut simplifier les choses si vous souhaitez vérifier si une chaîne est définie ou si un tableau a des valeurs.
Et comme indiqué.
expect(something).toBe(true)
etexpect(something).toBeTrue()
c'est pareil. Mais ceexpect(something).toBeTruthy()
n'est pas la même chose que l'un ou l'autre.la source
[] == false;
n'est pas correcte, la déclaration elle-même est fausse car les objets sont toujours véridiques[] == false;
esttrue
[""]==false
ou[0]== false
; pas vide, pas faux, juste trompeur ...x == true
que vous avez dans vos exemples est une manière trompeuse et, comme le montrent les commentaires ci-dessus, incorrecte d'illustrer le concept de véracité en JavaScript. Le véritable test de véracité en JavaScript est de savoir comment une valeur se comporte dans uneif
instruction ou en tant qu'opérande dans une expression booléenne. Nous savons que1
c'est la vérité parce queif (1)
cela entraînera l'évaluation de la prochaine déclaration. Il en va de même[]
pour la vérité pour la même raison: même si elle[] == true
évaluefalse
,if ([])
entraînera toujours l' évaluation de la prochaine déclaration, donc nous savons que[]
c'est la vérité.Je sais que tout le monde aime une liste facile à lire:
toBe(<value>)
- La valeur renvoyée est la même que<value>
toBeTrue()
- Vérifie si la valeur renvoyée esttrue
toBeTruthy()
- Vérifiez si la valeur, lorsqu'elle est convertie en booléen, sera une valeur de véritéLes valeurs Truthy sont toutes les valeurs qui ne sont pas
0
,''
(chaîne vide),false
,null
,NaN
,undefined
ou[]
(tableau vide) *.* Notez que lorsque vous exécutez
!![]
, il revienttrue
, mais lorsque vous exécutez,[] == false
il retourne égalementtrue
. Cela dépend de la manière dont il est mis en œuvre. En d'autres termes:(!![]) === ([] == false)
Sur votre exemple,
toBe(true)
ettoBeTrue()
donnera les mêmes résultats.la source
alert(!![])
[] == true
dans votre console produitfalse
.[] == false
dans votre console produittrue
Il y a beaucoup de bonnes réponses là-bas, je voulais juste ajouter un scénario où l'utilisation de ces attentes pourrait être utile. En utilisant
element.all(xxx)
, si j'ai besoin de vérifier si tous les éléments sont affichés en une seule fois, je peux effectuer -Raison d' être
.all()
retourne un tableau de valeurs et donc toutes sortes d'attentes (getText
,isPresent
, etc ...) peut être réalisée avectoBeTruthy()
quand.all()
vient en image. J'espère que cela t'aides.la source
reduce()
-en du tableau de booléens en une seule valeur puis en appliquant latoBe(true)
vérification. C'est beaucoup plus simple, merci.