Jak zorganizować testy jednostkowe i testy e2e w AngularJS?

Question

Potrzebuję zorganizować testy jednostkowe i testy od końca do końca dla mojej aplikacji JavaScript Single Page. Używam kątomierza AngularJS/Cucumber do testowania e2e i Chai do testów jednostkowych.

Mam testy e2e i jednostkowe w dwóch różnych folderach (folder unit i e2e) i obecnie nie korzystam z pattermu projektu page object. Pliki są nieustrukturyzowane i nie mają wiele wspólnego z kodem, więc powtarzam się wiele razy.

uznaję to podejście nie skaluje się

Czy istnieje najlepszych praktyk reorganizacji testy w taki sposób piszę najmniejszą ilość kodu, utrzymując suchą kodu test?

Answer 1

Przede wszystkim powinno się przełączyć się za pomocą wzoru Page Object i zachować swoje obiekty Strona w oddzielnym katalogu - Myślę, że jest to zalecane, aby zadzwonić do katalogu po.

Oto przykład dla ciebie, struktura projektu mamy obecnie:

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

config jest specjalny katalog, w którym trzymamy nasze protractor configs - nie mogło być wiele configs - na przykład do testowania lokalnego i testowanie na, powiedzmy, .

helpers to w zasadzie nasz katalog "libs"/"utils". Posiadamy niestandardowe jaśminowe matujące, dodatkowe "pomocnicze" moduły z funkcjami pomocniczymi. Ponadto mamy moduły localStorage i sessionStorage, które są wygodnymi opakowaniami wokół obiektów window.localStorage i window.sessionStorage. Jest to katalog, w którym przechowujemy protractor-http-mock mocks.

po to katalog, w którym zdefiniowano obiekty stron. Każdy obiekt strony w osobnym pliku.

specs to miejsce, w którym znajdują się wszystkie nasze specyfikacje - są one logicznie zorganizowane w podkatalogi.

---

Niektóre z bibliotek helpers są made globally available via global, przykład:

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

Ponadto, aby pomocników i PO import wygodniejsze i uniknąć przejeżdżające katalogi w drzewie i lepiej obsługiwać nestedness , mamy włączony do korzystania requirePO i requireHelper funkcji pomocnika sugerowanego przez @Michael Radionov patrz:

• Using require with relative paths

Bardzo podoba mi się również pomysł, zaproponowany przez @finspin, aby utworzyć pakiet węzłów z każdego obiektu strony.