Тестирование шаблонов в Протрактор?

Какой лучший способ написать утверждения, которые должны применяться на каждой странице сайта?

Я тестирую, существует ли элемент в нижнем колонтитуле моего сайта, поэтому элемент должен существовать на всех страницах.

Я подумываю написать отдельный файл для тестирования элементов шаблона сайта, а затем включить его во все спецификации. Кажется, что никто не делает это, хотя?

Ответы

Ответ 1

Прежде всего, для написания более чистых тестов и лучшего понимания того, из чего состоит ваш целевой сайт, примените шаблон объекта страницы и разделить части ваших веб-страниц на разные объекты страницы. Например, footer, header могут и должны быть отдельными объектами страниц, которые будут повторно использоваться на разных веб-страницах вашего сайта.

Подробнее о теме:

Насколько я понимаю, чтобы следовать принципу "СУХОЙ", вы хотите иметь какие-то "общие" спецификации жасмина, которые вы можете определить один раз и запустить в нескольких тестовых наборах.

Это именно то, что Сушка Jasmine Specs with Shared Behavior описывает статью. Идея довольно проста - определить функцию с вашими наборами тестов внутри и вызвать ее из других наборов тестов. Пример:

  • создать функцию, которая принимает объект контекстной страницы, и содержит специальные повторные тесты нижнего колонтитула:

    function testFooter(footer) {

    describe("(shared)", function () {

        describe("should show footer with necessary information", function () {
            it("should show copyright", function () {
                expect(footer.copyright.getText()).toEqual('Copyright 2014');
            });
        });

    });
}

  • вызов функции из других тестовых наборов, передающих объект страницы контекстного нижнего колонтитула:

    var FooterPage = require('./footer.po.js');

describe('Contacts page', function () {
    var scope = {};

    beforeEach(function () {
        browser.get('/contacts/');
        browser.waitForAngular();
        scope.page = new ContactsPage();
    });

    // other contacts page specific suites 
    // ...

    testFooter(new FooterPage());

});

Вам может потребоваться настроить и улучшить код, чтобы он работал, но идея остается прежней: определите один раз и повторно используйте. Прохождение объектов страницы просто делает его более чистым и прозрачным.

Также смотрите:

Ответ 2

Я использую спецификации таким образом, что спецификация говорит о некотором сценарии, а не только о конкретной странице, поэтому это не "одна спецификация, одна страница". Я бы подумал, что тестирование одной и той же вещи во многих спецификациях является плохим, если условия в спецификациях не могут влиять на присутствие вашего элемента.

В общем, я не думаю, что это даже необходимо проверять подобные вещи. Я бы предпочел бы, возможно ли даже, чтобы ваш элемент не присутствовал, или, если есть какие-то условия, которые влияют на это, и проверяйте эти ситуации.

Если вы настаиваете на его тестировании (например, есть статические страницы, которые не разделяют контент, а ваш элемент добавляется вручную, и вы должны быть уверены), я бы создал единую спецификацию для проверки наличия этого элемента и в там, определите список страниц для тестирования. Таким образом, тест будет охватывать тестирование присутствия этого элемента на всех перечисленных страницах.