- From: Robin Berjon <robin@w3.org>
- Date: Wed, 07 Aug 2013 12:05:45 +0200
- To: James Graham <james@hoppipolla.co.uk>
- CC: "Wang, Jing J" <jing.j.wang@intel.com>, Tobie Langel <tobie@w3.org>, public-test-infra@w3.org
On 07/08/2013 03:11 , James Graham wrote:
> That sounds like a bad idea :) It introduces significant complexity
> through a dependence on v8 and the glue code, merely to get javascript
> rather than python.
I knew you'd say that :)
> Another option is to build atop the mozbase http server [1]. This is
> already used internally for testing in Mozilla, so there is no problem
> deploying it in a large automated testing scenario. It is also
> relatively easy to customise, and doesn't require people running tests
> to have the ability to compile C code (or to ship binaries for lots of
> platforms).
That actually looks like a very decent starting point. We can easily add
API endpoints with specific behaviour that we need.
Do you know if API endpoints can be added and removed dynamically? The
sort of thing I have in mind would involve a way of doing the following:
POST /api/create-endpoint
{
"method": "GET",
"actions": [
200,
"h Content-Type: text/javascript",
"wait 2000",
"b foo()"
]
}
and it would return
201 CREATED
{ "endpoint": "/api/Xh23jY" }
which would be an endpoint, in existence for, say, an hour, that would
support the simple behaviour described. This would allow tests to create
the endpoints they need with custom behaviour without having to extend
the server, write scripts, etc. I reckon that with even a very simple
set of commands we can get a decent result.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Wednesday, 7 August 2013 10:05:51 UTC