Loading Config asynchronously

[axemclion]

Currently the configuration needs to be specified as an object in module.exports. This means that everything, include the browser capabilities need to be synchronous.

However, packages like firefox-profile are easier to use with their async API. Generating the zip and crx file for chrome extensions also work well with an async API.

What would be the best way to use the config where the capabilities object is generated asynchronously? Is this the best way of using protractor?

P.S: I am working on browser-perf and am looking at reusing protractor tests to test performance of Angular web apps. I am also generating the browser capabilities object asynchronously, hence this question.

[juliemr]

I'd be curious to learn if others have this same use case. If it's a common problem, then Protractor should introduce native support. Otherwise, using it as a library (as you linked) is probably the best way.

[axemclion]

Is there a full example of using it as the library? I would not want to replicate the runner.js code or the cli.js code.

Also, using it as a library would mean that I cannot double up measuring perf tests when running from CLI easily.

Does it make sense to support both sync as async? When the config object has promise methods, the async behavior is implied, else the normal case works.

[axemclion]

The problem with using protractor as a library is that protractor does not expose runners or config parsers. When using it as a library, would I have to re-write all the code to manually parse the library?

Given that q is already used in protractor, can the getConfig method return a promise? This way, both sync and async will be supported automatically.

[axemclion]

@juliemr Here is an example of how I am able to record performance metrics using existing protractor test cases - https://gist.github.com/axemclion/9594795

The only problem is that I am having to generate a temporary configuration and then run protractor. This way, I am able to add the additional browser configuration to the capabilities object.

I tried using it as a library, but realized that I was pretty much re-writing all the code from ConfigParser.js and Runner.js. Given that they are not exposed by protractor module, is there a way to reuse the config parser? Any other advice on how to structure this better so that it can work better with Protractor configurations and can be invoked directly from the command like, like protractor test?

[juliemr]

Hey, sorry for the slow responses here. You can always use the ConfigParser (even if it's not exposed) by doing require('protractor/lib/configParser')

The idea of using Protractor as a library was generally that you would want your own runner - that's why it's not exposed explicitly.

I like your solution of generating a temporary config for now.

[juliemr]

As mentioned in the pull request, I think adding complexity to the config isn't the way to go - prefer using the runner and launching yourself.

[axemclion]

For the sake of completeness adding information about the performance test suite here - The project https://github.com/axemclion/protractor-perf can be run just like protractor command line, with the same options. It also checks for perf regressions in addition to functional regressions.

[donaldpipowitch]

What is the best way to do it now? I'd love to have some async code in my configuration (or have #2334).