This repository has been archived on 2024-05-31. You can view files and clone it, but cannot push or open issues or pull requests.
authentik/tests/wdio/test/pageobjects
Ken Sternberg 4c6f84e522 web/add webdriverIO testing layer
This commit adds WebdriverIO as an end-to-end solution to unit testing.  WebdriverIO can be run both
locally and remotely, supports strong integration with web components, and is generally robust for
use in pipelines.  I'll confess to working through a tutorial on how to do this for web components,
and this is just chapter 2 (I think there are 5 or so chapters...).

There's a makefile, with help!  If you just run `make` it tells you:

```
Specify a command. The choices are:

  help                 Show this help
  node_modules         Runs `npm install` to prepare this feature
  precommit            Run the precommit: spell check all comments, eslint with sonarJS, prettier-write
  test-good-login      Test that we can log into the server. Requires a running instance of the server.
  test-bad-login       Test that bad usernames and passwords create appropriate error messages
```

... because Makefiles are documentation, and documentation belongs in Makefiles.

I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major
components (a page, a form, a wizard), there's a class that provides human-readable names for
human-interactable and human-viewable objects on the page.  The LoginPage object, for example, has
selectors for the username, password, submit button, and the failure alert; accessing those allows
us to test for items as expected., and to write a DSL for "a good login" that's as straightforward
as:

```
        await LoginPage.open();
        await LoginPage.login("ken@goauthentik.io", "eat10bugs");
        await expect(UserLibraryPage.pageHeader).toHaveText("My applications");
```

There was a *lot* of messing around with the LoginPage to get the username and password into the
system.  For example, I had to do this with all the `waitForClickable` and `waitForEnable` because
we both keep the buttons inaccessible until the form has something and we "black out" the page (put
a darkening filter over it) while accessing the flow, meaning there was a race condition such that
the test would attempt to interact with the username or password field before it was accessible.
But this works now, which is very nice.

``` JavaScript
    get inputUsername() {
        return $('>>>input[name="uidField"]');
    }

    get btnSubmit() {
        return $('>>>button[type="submit"]');
    }

    async username(username: string) {
        await this.inputUsername.waitForClickable();
        await this.inputUsername.setValue(username);
        await this.btnSubmit.waitForEnabled();
        await this.btnSubmit.click();
    }
```

The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my
guardrails.
2023-09-22 11:12:52 -07:00
..
admin-overview.page.ts web/add webdriverIO testing layer 2023-09-22 11:12:52 -07:00
admin.page.ts web/add webdriverIO testing layer 2023-09-22 11:12:52 -07:00
application-form.view.ts web/add webdriverIO testing layer 2023-09-22 11:12:52 -07:00
application-wizard.page.ts web/add webdriverIO testing layer 2023-09-22 11:12:52 -07:00
applications-list.page.ts web/add webdriverIO testing layer 2023-09-22 11:12:52 -07:00
ldap-form.view.ts web/add webdriverIO testing layer 2023-09-22 11:12:52 -07:00
login.page.ts web/add webdriverIO testing layer 2023-09-22 11:12:52 -07:00
oauth-form.view.ts web/add webdriverIO testing layer 2023-09-22 11:12:52 -07:00
page.ts web/add webdriverIO testing layer 2023-09-22 11:12:52 -07:00
types.ts web/add webdriverIO testing layer 2023-09-22 11:12:52 -07:00
user-library.page.ts web/add webdriverIO testing layer 2023-09-22 11:12:52 -07:00