2016-05-16 1 views
11

Dans l'un de nos tests, nous avons l'ensemble des attentes suivantes:Simplifier multiples contrôles booléens en une seule

expect(headerPage.dashboard.isDisplayed()).toBe(true); 
expect(headerPage.queue.isDisplayed()).toBe(true); 
expect(headerPage.claimSearch.isDisplayed()).toBe(true); 
expect(headerPage.claim.isDisplayed()).toBe(true); 
expect(headerPage.case.isDisplayed()).toBe(true); 
expect(headerPage.calendar.isDisplayed()).toBe(true); 

D'une part, ayant de multiples attentes simples fournissent une rétroaction plus précise et compréhensible, mais, sur un autre, cela ressemble à viole le principe DRY et le "une attente par test" directive généralement acceptée.

Existe-t-il un moyen de convertir/simplifier en un seul attendre?


headerPage est un objet Page, dashboard et d'autres champs d'objet page sont des liens de navigation.

Répondre

15

Je pense que vous avez mal compris le but de la directive « une attente par test ». Il ne s'agit pas de combiner un ensemble d'attentes en une seule attente, mais de diviser vos attentes en tests distincts.

Pour suivre l'esprit de cette directive, vous écririez vos tests comme ceci:

describe("The header page", function() { 
    var headerPage; 
    beforeEach(function() { 
     //Common logic here 
    }); 

    it("displays the dashboard", function() { 
     expect(headerPage.dashboard.isDisplayed()).toBe(true); 
    }); 

    it("displays the queue", function() { 
     expect(headerPage.queue.isDisplayed()).toBe(true); 
    }); 

    it("displays the claimSearch", function() { 
     expect(headerPage.claimSearch.isDisplayed()).toBe(true); 
    }); 

    //etc. 
}); 

C'est un peu juste plus bavard que ce que vous avez; mais c'est pourquoi ce sont des lignes directrices et non des règles. C'est un compromis entre la façon dont vous faites vos tests verbeux, et la facilité avec laquelle ils seront débugués plus tard. ("La page d'en-tête affiche le tableau de bord: FAILED") est un message d'échec de test très clair et spécifique, comparé à l'obtention du même message d'échec, quelle que soit l'attente réellement échouée.

Je n'essaierais certainement pas de combiner toutes ces lignes en une seule ligne. Si vous ne voulez pas le diviser en un tas de cas de test différents, je le laisserais tel quel.

+0

Cela prend tout son sens. Je pense aussi à l'aborder différemment - avoir une méthode d'objet de page qui retournerait les liens de navigation visuels courants et l'affirmerait à la place. Va également poster ici quand prêt. Merci beaucoup! – alecxe

+0

FYI, posté ce que j'ai fini avec. – alecxe

-1

ce que sur l'utilisation d'une fonction d'aide qui renvoie les résultats de tous les tests, quelque chose comme

expect(headerDisplayTests()).toBe(true); 

function headerDisplayTests() { 
    return headerPage.dashboard.isDisplayed() && 
      headerPage.queue.isDisplayed() && 
      headerPage.claimSearch.isDisplayed() && 
      headerPage.claim.isDisplayed() && 
      headerPage.case.isDisplayed() && 
      headerPage.calendar.isDisplayed(); 
} 
+1

Merci , Je pensais à l'astuce "Extraire la méthode", mais cela ne fonctionnerait pas car 'isDisplayed()' renvoie une promesse..'protracto r.promise.all() 'serait nécessaire ici. S'il vous plaît voir si vous pouvez ajuster la réponse pour en tenir compte. – alecxe

+0

si isDisplay() renvoie une promesse, alors comment votre exemple d'expect (headerPage.dashboard.isDisplayed()). ToBe (true); jamais travaillé? – nuway

+0

Oui, parce que protractor a le correctif attendu pour résoudre implicitement les promesses .. – alecxe

1

Approche alternative. Ce que j'ai fini avec était d'ajouter une méthode d'objet page qui renvoie les étiquettes des liens de navigation actuellement visible:

this.getVisibleLinks = function() { 
    return $$(".ap-header-nav-tabs li a").filter(function (link) { 
     return link.isDisplayed(); 
    }).getText(); 
}; 

Ensuite, le test ci-dessus serait transformé en un concise et lisible:

expect(headerPage.getVisibleLinks()).toEqual(["Dashboard", "Queue", "Claim Search", ...]); 
1

Si cela est logique que vous utilisez plusieurs spécifications, vous pouvez regarder dans le jasmin custom matchers pour encapsuler la logique.

Il serait écrit un peu comme ceci:

var customMatchers = { 
    toDisplayWidgets: function(util, customEqualityTests) { 
     return { 
      compare: function(actual, expected) { 
        function isDisplayingWidgets(page) { 
         return page.dashboard.isDisplayed() && 
          page.queue.isDisplayed() && 
          page.claimSearch.isDisplayed() && 
          page.claim.isDisplayed() && 
          page.case.isDisplayed() && 
          page.calendar.isDisplayed(); 
        } 

        var result = {}; 
        result.pass = isDisplayingWidgets(actual); 

        if (!result.pass) { 
         result.message = 'dashboard is not displayed'; 
        } 

        return result; 
      } 
    } 
} 

Ajouter la matcher à votre test en cours

jasmine.addMatchers(customMatchers); 

Et puis dans vos tests, vous pouvez simplement affirmer avec

expect(headerPage).toDisplayWidgets();