Extensions: adding new runners/environments

[August Lilleaas]

Hey folks,

I've been chatting with Garrick on IRC about adding a new "selenium"
environment for the buster-selenium extension. For now, the extension
uses the "node" environment. But it seems to make more sense to me if
the extension provided a new environment, "selenium".

FYI: the buster-selenium extension is a completely new thing, to use
buster to talk to selenium. It's not about using selenium to capture
browsers for buster-server.

The "selenium" env would be a mix of node and browser. The actual
run-time is in node, and tests will execute in node, and communicate
in-process to the reporter, just like the node env. The web page will of
course run in the browsers, via selenium, but the API to tell selenium
to do stuff, and ask selenium about the current state of the web page,
is done through Node.JS and the selenium node package. But there will be
multiple selenium browsers configured, that will run in parallel. So
in-process, we need to create multiple instances of .... whatever ...
and report back with different groups/user agents, just like the browser
env does.

So it seems to make sense to me to create a new environment for this,
that does the required wiring to get a node run-time but parallel test runs.

Chris has told me that the last rewrite before 1.0 is the runner code.
Perhaps this discussion is relevant to that rewrite.

BTW: Should we unify naming? Runners are called "env" in the config file
and cli. Should we rename to "runner" in config file, or "env" in
backend code?

[Christian Johansen]

> I've been chatting with Garrick on IRC about adding a new "selenium"
> environment for the buster-selenium extension. For now, the extension
> uses the "node" environment. But it seems to make more sense to me if
> the extension provided a new environment, "selenium".
>
> FYI: the buster-selenium extension is a completely new thing, to use
> buster to talk to selenium. It's not about using selenium to capture
> browsers for buster-server.
>
> The "selenium" env would be a mix of node and browser. The actual
> run-time is in node, and tests will execute in node, and communicate
> in-process to the reporter, just like the node env. The web page will of
> course run in the browsers, via selenium, but the API to tell selenium
> to do stuff, and ask selenium about the current state of the web page,
> is done through Node.JS and the selenium node package. But there will be
> multiple selenium browsers configured, that will run in parallel. So
> in-process, we need to create multiple instances of .... whatever ...
> and report back with different groups/user agents, just like the browser
> env does.

I've made some notes and many thoughts for a rewrite of the current
runners to that "... whatever ..." you're referring to, and when I get
this done (I've forced Magnar to help me after having rubber-ducked
these issues with him multiple times), creating a new environment like
the one you describe should be quite doable.

> So it seems to make sense to me to create a new environment for this,
> that does the required wiring to get a node run-time but parallel test runs.
>
> Chris has told me that the last rewrite before 1.0 is the runner code.
> Perhaps this discussion is relevant to that rewrite.
>
> BTW: Should we unify naming? Runners are called "env" in the config file
> and cli. Should we rename to "runner" in config file, or "env" in
> backend code?

Naming probably should be cleaned up - but we're not renaming any more
config stuff. I don't want more user-facing breaking changes. Renaming
"runner" to "environment" in the code is a good suggestion.

Christian