How to organize unit tests and e2e tests in AngularJS?

Question

I need to organize unit tests and end-to-end tests for my application for a single JavaScript page. I am using AngularJS Protractor / Cucumber to test e2e and Chai for unit tests.

I have e2e and unit tests in two different folders ( unit and e2e ) and I currently do not use the design patterm page object . Files are unstructured and do not have a lot of code, so I repeat many times.

I understand that this approach does not scale

Is there a best practice for reorganizing tests in this way, I write the least amount of code while keeping the DRY test code?

Answer 1

First of all, you should definitely switch to using the page object template and save the objects of your page in a separate directory - I think it is recommended to call the po directory.

Here is a sample for you, the project structure that we currently have:

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

config - this is a special directory in which we save our protractor configurations - there can be several configurations - for example, for local testing and testing, for example, BrowserStack .

helpers is basically our directory "libs" / "utils". We keep special jasmine matches, additional "auxiliary" modules with auxiliary functions. In addition, we have localStorage and sessionStorage , which are convenient wrappers around window.localStorage and window.sessionStorage objects.

mocks is the directory in which we store protractor-http-mock mocks .

po is the directory in which page objects are defined. Each page object in a separate file.

specs is where all our specifications live - they are logically organized into subdirectories.

---

Some of the helpers libraries helpers made globally accessible through global , for example:

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

In addition, to make helpers and po import more convenient and to avoid directory movement in the tree and to better handle nesting, we switched to using the requirePO and requireHelper helper functions proposed by @Michael Radionov, see

• Using require with relative paths

I also really like the idea suggested by @finspin to make a node package from each page object.