CPS-562: E2E test Basic Structure

[deb1990]

Overview

This PR Creates a basic structure for E2E tests using Playwright, Jest and Gulp.

Technical Details

Refer https://github.com/compucorp/cases-product-suite-e2e-tests/blob/CPS-562-e2e-basic-setup/readme.md.

[pubududp]

@deb1990 Please move all the selectors within page classes to variables and then reuse the variables inside the tests. To make it a bit more accessible we can create array and pop all the elements inside the array so we can refer to elements by "PageName.selectors.ElementName"

eg:
static selectors = {
usernameTextBox: 'input[data-test="username"]',
passwordTextBox: 'input[data-test="password"]',
loginButton: 'input[data-test="login-button"]'
};

This would be useful when tests are using elements from more than one page in E2E scenarios.

[reneolivo]

@deb1990 @tunbola @lisandro-compucorp have we considered the use of Cucumber for writing the spec files?

I have the Gherkin syntax much more readable and explanatory. I think writing new tests can be easier as well.

Instead of having an intimidating file such as
tests/prospects/manage-prospects/prospect-page-title.spec.ts

We can have something like

Feature: Prospect Dashboard

Scenario: Prospect Dashboard Title
  When I log in as a "Prospect User"
  And I navigate to the "Prospect Dashboard"
  Then the page title should be "Manage Prospectings"

Scenario: Restricted Access
  When I log in as a "CiviCRM User"
  And I navigate to the "Prospect Dashboard"
  Then I should get an access denied message

The cool thing about these examples is that we can reuse sentences in other spec files.
The "Given I log in as a *" can be defined in code as follows:

Given("I log in as a {string}", function (userRole) {
  await browser.loginUsingCookiesAs(userRole);
});

Once we define things like "login as" or "navigate to", we don't need to define these in the code again, and again. We just need to mention the steps in the spec files.

The Gherkin files also remove a lot of code that is necessary to run tests but not to understand what
we want to test such as

  beforeAll(async () => {
    await browser.setup();
  });

  afterAll(async () => {
    await browser.close();
  });

  beforeEach(async () => {
    page = await browser.newPage();

    manageProspects = new ManageProspects(browser);
  });

  afterEach(async () => {
    await browser.takeScreenshotWhenFailedAndClose(page);
  });

And even code that is perfectly readable for programmers can be more easily understood in a test context:

await manageProspects.navigate(page);
await manageProspects.waitForPageLoad(page);

vs

And I navigate to "Prospect Dashboard"

Let me know what you guys think and we can discuss in detail.

[reneolivo]

Why document the type when TypeScript is already doing that?

I don't see much value in adding these unless there's a specific note to add.

[reneolivo]

I also think the return value is inferred by TypeScript because there is no return and because of async. TypeScript would usually infer the return value and there is no need to define it in most cases. Unless we want to make it a rule to always define it.

[deb1990]

Yeah Standard JS is enforcing this, which is fine because now we are documenting the return type anymore using JSDoc.

[reneolivo]

We can define every possible parameter here, but different API endpoints have different parameters. This list might grow exponentially over time.

The actual type for API parameters would be

{
  [key: string]: any,
}

[deb1990]

Right, in that case, should we not use any type? Because [key: string]: any, defeats the purpose, or what do you think?

[reneolivo]

[key: string]: any is a bit more specific than any because I don't think you can pass numbers to that parameter.

[reneolivo]

No need to define the constructor method if we are not going to have a different behaviour from the base class.

[reneolivo]

No need to redefine this one either.

[reneolivo]

No need to define the return type. TypeScript knows that you are returning a string.

[deb1990]

This is enforced by StandardJS.

[reneolivo]

please remove

[reneolivo]

please remove

[reneolivo]

From experience, I try not to add the return type at all. TypeScript is smart enough to determine the return type. And if it doesn't figure it out, it means one of your function call return types is not properly defined. It's easier to debug proper TypeScript when you don't add the return type hint.

[deb1990]

This is enforced by StandardJS.

[reneolivo]

You can import things from the root if configured:

https://stackoverflow.com/questions/42123382/import-module-from-root-path-in-typescript

import BrowserService from '../../../src/services/utils/browser.service';
// vs
import BrowserService from 'services/utils/browser.service';

[reneolivo]

Even better when you don't have to count the number of folders to go back.

[deb1990]

Absolute paths are currently not supported in ts-node. wclr/ts-node-dev#95

I tried some of the solutions mentioned, but its not working and I have already spent a lot of time in this. Lets leave this for now, I will keep trying.

[reneolivo]

Don't worry about this, but if you want to check this in the future it seems this can work:
https://dev.to/larswaechter/path-aliases-with-typescript-in-nodejs-4353

I have also created a package.json file in the src folder and then reference it in the root package.json. Like this:

// /package.json
{
  "dependencies": {
    "cases-e2e": "./src"
  }
}

// /src/pacakge.json
{
  "name": "cases-e2e"
}

Then on any TS file I can do this:

import something from 'cases-e2e/a/path/from/src/something';

[tunbola]

We should switch the branch to be cloned here to master