Comments (14)
Oh, thanks. That's great feedback! I wasn't that happy with the mix generator style / callback style, so thanks for pointing out that we should be able to solve it in another way.
I like the simplicity with the current API and what you're suggesting (with keeping track of process.on('exit')
) seem a bit more complex to me, so I think that there's room for some iteration on this!
How do you think about a flow that works somewhat like this?
var each = require('co-each')
var runners = yield require('co-webdriver-runner')({ baseConfig: '...', browsers: '...', local: false })
yield each(
runners
, function* (runner) {
var test = runner.test
var browser = runner.browser
// this means that here the browser won't be initialized, so you need to do stuff with it in a test-scope
test('title', function* (t) {
// ...
})
// in start we initialize the browser
// and then run the tests
yield runner.start()
}
)
from co-webdriver-runner.
yeah...what do you think about this?
var test = runner({ ... });
yield test('name', function*(t){
// use t.browser or test.browser
});
yield test...
I think this would be the nicest and most consistent api
EDIT and you don't need process.on('exit')
from co-webdriver-runner.
both would work! but if a saw your last example in a readme i guess i'd be hesitant to use the module, because of the amount of code needed to get startet
from co-webdriver-runner.
+1 @juliangruber to this approach, great thinking here. seems more digestible when reading.
@kesla this is looking really good! excited to put this to use :)
from co-webdriver-runner.
@juliangruber How would you setup something specific for a browser with your suggestion? Let's say a http-server running on a certain port for every browser?
from co-webdriver-runner.
@kesla can you explain further please?
from co-webdriver-runner.
@juliangruber Sure, to speedup the running times the tests are ran in parallel when ran on sauce labs. Every browser is queued and executed as quickly as possible. Looking at runner.js from condor, we then start one separate http-server for each browser and one instance of localtunnel
to make them reachable from the outside world. This is also the reason we're creating multiple tap-harnesseses here, so that the result from each browser can be buffered up and then presented in one go, when that browser has finished running.
from co-webdriver-runner.
ok i think i get it^^
wouldn't you orchestrate your tests just the same as with the current api?
really, i think we can get rid of all yield
and just have it be
var test = require('runner')(opts);
test('foo', function*(t){
// use t.browser
});
so it's mostly the same api as tap
from co-webdriver-runner.
Hm, I'm still having troubles understanding exactly what you mean.
In the current api each combination of a test-instance and browsers are ran in a closure, so that a specific server address can be used for that browser. How would you get that using the above api? Is opts
here options for one browser or multiple browsers?
from co-webdriver-runner.
If opts
here is for one browser, I'm having trouble understanding how one could write a simple example without a lot of setup-code.
from co-webdriver-runner.
opts
has .baseConfig
, .browsers
and .local
for example
from co-webdriver-runner.
instead of running the tests closure for every browser, the api from the comment above would behind the scenes fan out to all the browsers
so
test('foo', function*(t){
// ...
})
really becomes
tests.push(function*(t){
// ...
});
// after all the tests
each(browsers, function*(){
runTests(tests)
})
from co-webdriver-runner.
Alright, but then I wouldn't be able to orchestrate the tests the same way as we do today in condor.
Today we're in a closure with the test-variable & browser-variable, so I'm setting up a server for each browser, a server that each browser instance then can use. Basically, I'm doing stuff in the browser where I'm then looking at events in the server. For example I'm clickin on a link, I then test that the server that the event was sent correctly.
Also, I think that there's a risk of confusing with your proposed api - we would have something looking very much like ordinary tap/gap but where the behaviour is quite different.
from co-webdriver-runner.
i'm probably not understanding probably...my understanding is that this would roughly expose the current module through my proposed api: https://gist.github.com/d680eef1a755ecbb23eb
from co-webdriver-runner.
Related Issues (2)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from co-webdriver-runner.