Как организовать модульные тесты и тесты e2e в AngularJS?

Question

Мне нужно организовать модульные тесты и тесты завершения для моего приложения для одиночной страницы JavaScript. Я использую AngularJS Protractor/Cucumber для тестирования e2e и Chai для модульных тестов.

У меня есть тесты e2e и unit в двух разных папках (unit и e2e папка), и я в настоящее время не пользуюсь шаблоном дизайна page object. Файлы неструктурированы и не имеют большого количества кода, поэтому я повторяюсь много раз.

Я понимаю, этот подход не масштабируется до

Есть ли лучшая практика реорганизовать испытания таким образом, я пишу наименьшее количество кода, сохраняя тестовый код DRY?

Answer 1

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

Вот пример для вас, структура проекта в настоящее время мы имеем:

$ cd e2e 
$ tree -L 1 
. 
├── config 
├── db 
├── helpers 
├── mocks 
├── po 
└── specs 

config специальный каталог, где мы держим наши protractor конфиги - там может быть несколько конфиги - например, для локального тестирования и тестирование, скажем, .

helpers есть, в основном, наш каталог «libs»/«utils». Мы сохраняем специальные жасминовые матчи, дополнительные «вспомогательные» модули со вспомогательными функциями. Также у нас есть модули localStorage и sessionStorage, которые являются удобными обертками вокруг window.localStorage и window.sessionStorage объектов.

mocks - это каталог, в котором мы храним protractor-http-mock mocks.

po - это каталог, в котором заданы объекты страницы. Каждый объект страницы в отдельном файле.

specs - это где все наши спецификации живут - они логически организованы в подкаталоги.

---

Некоторые из helpers библиотек made globally available via global, пример:

onPrepare: function() { 
    global.helpers = require("../helpers/helpers.js"); 
    // ... 
}, 

Кроме того, чтобы сделать хелперов и ро импорт более удобным и избежать обхода каталогов в дереве и, чтобы лучше справиться с nestedness мы перешли на использование requirePO и requireHelper вспомогательную функцию, предложенную @Michael Радионов, см:

• Using require with relative paths

Мне также очень нравится идея, предложенная @finspin, сделать пакет узлов из каждого объекта страницы.