[Django] #32606: Allow rich configuration of Selenium tests
Django
---------------------------------------------+------------------------
Reporter: Dominik George | Owner: nobody
Type: New feature | Status: new
Component: Testing framework | Version: dev
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
---------------------------------------------+------------------------
Currently, the SeleniumTestCase allows passing a list of browsers to run
tests with.
I propose to extend this feature from a flat list of strings to the
following:
A dictionary mapping browsers to a list of dictionaries can be passed. The
key is the name of the browser (the same string that was currently passed
in the browsers list), and the list contains dictionaries of capabilities
that are passed to the respective browsers.
The use case is testing with the same browser with different settings.
e.g. different screen resolutions, different versions (possible with
BrowserStack), etc.
I am willing to implement this change if the idea is accepted.
--
Ticket URL: <https://code.djangoproject.com/ticket/32606>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Dominik George | Owner: nobody
Type: New feature | Status: new
Component: Testing framework | Version: dev
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham):
Can you think of a suitable alternative to passing complex data structures
on the command line? That seems a little verbose and tricky with issues
like character escaping. Something like
`--selenium={\"foo\":[{\"bar\":\"baz\"}]}` doesn't look so nice to me.
Maybe reading configurations from a file?
--
Ticket URL: <https://code.djangoproject.com/ticket/32606#comment:1>
Django
Reporter: Dominik George | Owner: nobody
Component: Testing framework | Version: dev
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: new => closed
* resolution: => needsinfo
--
Ticket URL: <https://code.djangoproject.com/ticket/32606#comment:2>
Django
Reporter: Dominik George | Owner: nobody
Type: New feature | Status: new
Component: Testing framework | Version: dev
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Dominik George):
* status: closed => new
* resolution: needsinfo =>
Comment:
I did not think of passing such configuration on the command-line.
Reading from a file would be an optoin, of course. Or hard-coded in the
test suite.
--
Ticket URL: <https://code.djangoproject.com/ticket/32606#comment:3>
Django
Reporter: Dominik George | Owner: nobody
Component: Testing framework | Version: dev
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* status: new => closed
* resolution: => wontfix
Comment:
Hi Dominik.
I'm going to say wontfix here initially. That doesn't mean definitely not,
just that it seems out of scope for what we'd include in Django itself.
If you want to pull together a proof-of-concept, it's something we could
look at. (And happily so!) (So I'm tempted towards `needsinfo` again for
that reason.)
**Maybe** what you're suggesting would be a trivial pass-through to
selenium, but a quick initial look browser capabilities there presents a
wall of posts and docs that aren't exactly inviting, so it's hard to
assess.
(New features like this often need some idea of what's really involved,
and we often begin with discussion on the DevelopersMailingList, which has
a larger audience, rather than straight here on Trac, which is better for
concrete addressable with a plan.)
I hope that makes sense.
--
Ticket URL: <https://code.djangoproject.com/ticket/32606#comment:4>