Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An Interface For Running Tests Headlessly #49

Open
jameshopkins opened this issue Nov 22, 2016 · 2 comments
Open

An Interface For Running Tests Headlessly #49

jameshopkins opened this issue Nov 22, 2016 · 2 comments
Labels

Comments

@jameshopkins
Copy link
Collaborator

jameshopkins commented Nov 22, 2016

The three main use cases I envisage for running tests are:

  1. using the UI and being provided visual feedback as part of a one-off process
  2. integration into a CI/CD pipeline, where the process would be run as a build step to catch potential regressions introduced by new code in the release. It should have the ability to abort the deploy process if the SpeedIndex score dropped below a certain threshold, for example.
  3. execution as part of a continuous cycle (at a user defined frequency) to check for sporadic latency introduced by external resources, such as JS and CSS files.

The last two 'headless' concepts haven't really been discussed before, but I think will likely be the most common use cases.

This ticket is a place to discuss both feature requirements and the interface we want to provide to allow for this.

Requirements

  • A visual interface in which to view and analyse previous test runs - this should be a cross-cutting concern of both the headless and visual interface.
  • Parity of test configuration options relative to the visual interface - i.e scripting, etc.

Lets addd some more!

@charypar
Copy link
Collaborator

I believe 2. and 3. can be merged - i.e. I would leave the repeated execution on the consumer.

I would almost say the CI/CD story is basically an API story - provide a good public REST API to configure and run a test, then get results streamed / fetch them by polling. We can even provide a CLI consuming this API for use in CI automation (and write it in Go, mwahahaha!). But the rest of it - success thresholds, etc., the consumers can do with the API on their own.

The tricky thing about testing the current release and catching regressions is you'd need to first deploy it to production environment (or one that has comparable performance characteristics) in order to have a URL to give to WebAppTest.. this seems almost impossible for most projects, so the use-case as a regression test to stop a build seems relatively minor...

@lpil
Copy link

lpil commented Nov 22, 2016

and write it in Go

I vote Rust because monads and types <3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants