W3C home > Mailing lists > Public > public-test-infra@w3.org > October to December 2013

Re: Testing and certificates

From: David Burns <dburns@mozilla.com>
Date: Fri, 11 Oct 2013 17:20:00 +0100
Message-ID: <52582530.9030104@mozilla.com>
To: James Graham <james@hoppipolla.co.uk>
CC: "public-test-infra@w3.org" <public-test-infra@w3.org>
I honestly don't see that there should be any difference between 1 and 3.

If a browser vendor wants their tests to be supported for individuals, 
like through Test the Web Forward, they should come to the party and 
make things testable. E.g. Mozilla has libraries for making automation 
easier[1] and I can't see why other vendors can't or won't do that.

**Biased Thoughts**

Getting something like WebDriver to start the browser and just leave it 
there for the user to use would get around the cert issues (except for 
Internet Explorer since we don't have vendor help _currently_). Its a 
dependency managed by a great OSS team and since the user base is huge 
they wont be breaking it any time soon!


from selenium import webdriver
browser = webdriver.Firefox() # Other browsers are available :)


On 11/10/2013 14:08, James Graham wrote:
> A number of our tests require resources to be avaliable over SSL, 
> either as HTTP or WSS. This is problematic because it is unclear how 
> to deal with the certificates. We have three main deployment scenarios:
> 1) On vendor automation
> 2) On w3c-test.org
> 3) On individual machines for development
> 1) is typically a solved problem for vendors. For example Mozilla has 
> its own "CA" for test purposes. When starting a test run a new profile 
> is created and the CA is added to the profile. At the end of the test 
> run the profile is deleted. Therefore no real user profile ever trusts 
> the fake CA.
> 2) Is easy. We get a real cert.
> 3) Is hard. The options are "make the user add a fake CA in their 
> browser" (extreme badness), "make the test environment setup 
> browser-specific so that we can act like the automation case above" 
> (i.e, for each "supported" browser have the test environment setup 
> launch that browser with the CA trusted for that session only, and 
> force people to use that instance for testing), which is several other 
> kinds of badness since it forces browser-specific code into 
> web-platform-tests and rquires the user to carefully follow 
> instructions, and "don't support ssl-requiring tests in this 
> scenario", which makes developing tests and casually running specific 
> tests hard.
> Does anyone have another option for 3). Failing that do they have an 
> opinion on the right way to proceed here?
Received on Friday, 11 October 2013 16:20:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:34:10 UTC