- 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