20dde50ed3
* 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. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * web: improve testing by adding test admin user via blueprint * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
161 lines
6.1 KiB
TypeScript
161 lines
6.1 KiB
TypeScript
import type { Options } from "@wdio/types";
|
|
|
|
export const config: Options.Testrunner = {
|
|
//
|
|
// ====================
|
|
// Runner Configuration
|
|
// ====================
|
|
// WebdriverIO supports running e2e tests as well as unit and component tests.
|
|
runner: "local",
|
|
autoCompileOpts: {
|
|
autoCompile: true,
|
|
tsNodeOpts: {
|
|
project: "./tsconfig.json",
|
|
transpileOnly: true,
|
|
},
|
|
},
|
|
|
|
//
|
|
// ==================
|
|
// Specify Test Files
|
|
// ==================
|
|
// Define which test specs should run. The pattern is relative to the directory
|
|
// of the configuration file being run.
|
|
//
|
|
// The specs are defined as an array of spec files (optionally using wildcards
|
|
// that will be expanded). The test for each spec file will be run in a separate
|
|
// worker process. In order to have a group of spec files run in the same worker
|
|
// process simply enclose them in an array within the specs array.
|
|
//
|
|
// If you are calling `wdio` from an NPM script (see https://docs.npmjs.com/cli/run-script),
|
|
// then the current working directory is where your `package.json` resides, so `wdio`
|
|
// will be called from there.
|
|
//
|
|
specs: ["./test/specs/**/*.ts"],
|
|
// Patterns to exclude.
|
|
exclude: [
|
|
// 'path/to/excluded/files'
|
|
],
|
|
//
|
|
// ============
|
|
// Capabilities
|
|
// ============
|
|
// Define your capabilities here. WebdriverIO can run multiple capabilities at the same
|
|
// time. Depending on the number of capabilities, WebdriverIO launches several test
|
|
// sessions. Within your capabilities you can overwrite the spec and exclude options in
|
|
// order to group specific specs to a specific capability.
|
|
//
|
|
// First, you can define how many instances should be started at the same time. Let's
|
|
// say you have 3 different capabilities (Chrome, Firefox, and Safari) and you have
|
|
// set maxInstances to 1; wdio will spawn 3 processes. Therefore, if you have 10 spec
|
|
// files and you set maxInstances to 10, all spec files will get tested at the same time
|
|
// and 30 processes will get spawned. The property handles how many capabilities
|
|
// from the same test should run tests.
|
|
//
|
|
maxInstances: 1,
|
|
//
|
|
// If you have trouble getting all important capabilities together, check out the
|
|
// Sauce Labs platform configurator - a great tool to configure your capabilities:
|
|
// https://saucelabs.com/platform/platform-configurator
|
|
//
|
|
capabilities: [
|
|
{
|
|
"browserName": "chrome",
|
|
"goog:chromeOptions": {
|
|
args: ["--disable-infobars", "--window-size=1280,800"].concat(
|
|
(function () {
|
|
return process.env.HEADLESS_CHROME === "1"
|
|
? [
|
|
"--headless",
|
|
"--no-sandbox",
|
|
"--disable-gpu",
|
|
"--disable-setuid-sandbox",
|
|
"--disable-dev-shm-usage",
|
|
]
|
|
: [];
|
|
})(),
|
|
),
|
|
},
|
|
},
|
|
],
|
|
|
|
//
|
|
// ===================
|
|
// Test Configurations
|
|
// ===================
|
|
// Define all options that are relevant for the WebdriverIO instance here
|
|
//
|
|
// Level of logging verbosity: trace | debug | info | warn | error | silent
|
|
logLevel: "info",
|
|
//
|
|
// Set specific log levels per logger
|
|
// loggers:
|
|
// - webdriver, webdriverio
|
|
// - @wdio/browserstack-service, @wdio/devtools-service, @wdio/sauce-service
|
|
// - @wdio/mocha-framework, @wdio/jasmine-framework
|
|
// - @wdio/local-runner
|
|
// - @wdio/sumologic-reporter
|
|
// - @wdio/cli, @wdio/config, @wdio/utils
|
|
// Level of logging verbosity: trace | debug | info | warn | error | silent
|
|
// logLevels: {
|
|
// webdriver: 'info',
|
|
// '@wdio/appium-service': 'info'
|
|
// },
|
|
//
|
|
// If you only want to run your tests until a specific amount of tests have failed use
|
|
// bail (default is 0 - don't bail, run all tests).
|
|
bail: 0,
|
|
//
|
|
// Set a base URL in order to shorten url command calls. If your `url` parameter starts
|
|
// with `/`, the base url gets prepended, not including the path portion of your baseUrl.
|
|
// If your `url` parameter starts without a scheme or `/` (like `some/path`), the base url
|
|
// gets prepended directly.
|
|
baseUrl: "http://localhost",
|
|
//
|
|
// Default timeout for all waitFor* commands.
|
|
waitforTimeout: 10000,
|
|
//
|
|
// Default timeout in milliseconds for request
|
|
// if browser driver or grid doesn't send response
|
|
connectionRetryTimeout: 120000,
|
|
//
|
|
// Default request retries count
|
|
connectionRetryCount: 3,
|
|
//
|
|
// Test runner services
|
|
// Services take over a specific job you don't want to take care of. They enhance
|
|
// your test setup with almost no effort. Unlike plugins, they don't add new
|
|
// commands. Instead, they hook themselves up into the test process.
|
|
// services: [],
|
|
//
|
|
// Framework you want to run your specs with.
|
|
// The following are supported: Mocha, Jasmine, and Cucumber
|
|
// see also: https://webdriver.io/docs/frameworks
|
|
//
|
|
// Make sure you have the wdio adapter package for the specific framework installed
|
|
// before running any tests.
|
|
framework: "mocha",
|
|
//
|
|
// The number of times to retry the entire specfile when it fails as a whole
|
|
// specFileRetries: 1,
|
|
//
|
|
// Delay in seconds between the spec file retry attempts
|
|
// specFileRetriesDelay: 0,
|
|
//
|
|
// Whether or not retried spec files should be retried immediately or deferred to the end of the queue
|
|
// specFileRetriesDeferred: false,
|
|
//
|
|
// Test reporter for stdout.
|
|
// The only one supported by default is 'dot'
|
|
// see also: https://webdriver.io/docs/dot-reporter
|
|
reporters: ["spec"],
|
|
|
|
//
|
|
// Options to be passed to Mocha.
|
|
// See the full list at http://mochajs.org/
|
|
mochaOpts: {
|
|
ui: "bdd",
|
|
timeout: 60000,
|
|
},
|
|
};
|