Edit: This has since been solved as an interesting network issue, see my comments and answer below.
Original Post:
My goal: Setup proof-of-concept tests on BrowserStack with Intern.
I went through the intern-tutorial, which all worked beutifully for me on Sauce Labs, and now I just want to learn what it takes to modify that configuration to test on BrowserStack, which keeps failing for me.
The terminal command, as per the tutorial:
./node_modules/.bin/intern-runner config=tests/intern
When running that, I get:
Listening on 0.0.0.0:9000
Starting tunnel...
BrowserStackLocal v2.2
Connecting to BrowserStack using WebSocket protocol...
Connected.
Ready
Error: connect ETIMEDOUT
at errnoException <net.js:904:11>
at Object.afterConnect [as oncomplete] <net.js:895:19>
TOTAL: tested 0 platforms, 0/0 tests failed; fatal error occurred
Environment:
OS: Mac OS X 10.9.4
Node: 0.10.29
NPM: 1.4.21
Intern: 2.0.1
Variables set in ~/.bash_profile as:
export BROWSERSTACK_USERNAME="<my_actual_username>"
export BROWSERSTACK_ACCESS_KEY="<my_actual_access_key>"
Intern configuration set in tests/intern as:
define({
proxyPort: 9000,
proxyUrl: 'http://localhost:9000/',
capabilities: {
'selenium-version': '2.41.0'
},
environments: [
{ os: "Windows", os_version: "8.1", browser: "chrome", browser_version: "34.0" }
],
maxConcurrency: 3,
tunnel: 'BrowserStackTunnel',
tunnelOptions: {
verbose: true
},
loader: {
packages: [ { name: 'app', location: 'app' } ]
},
suites: [ 'tests/hello' ],
functionalSuites: [ 'tests/functional/index' ],
excludeInstrumentation: /^(?:tests|node_modules)\//
});
As in, this is all that has been changed since the completed tutorial:
Removed all but one environment object (for simplicity), modified it to a format supported by BrowserStack.
Set the 'tunnel' property to the appropriate tunnel class.
Set tunnelOptions: { verbose: true } for debugging.
Things I've tried:
Setting BROWSERSTACK_USERNAME and BROWSERSTACK_ACCESS_KEY inline on the command line when executing the runner, just in case.
Used the configuration here (which I recognize is out of date): https://stackoverflow.com/questions/23304388/intern-js-and-browserstack
Stupidity checks, computer reboots, etc.
My environment object should be valid, as its based on one coming back from:
https://www.browserstack.com/automate/browsers.json
I feel like there's some basic thing here I'm missing about the configuration.
Can you have a look into the intern config file, which I use to run tests on browserstack. Hope it will help you solve your problem.
I have confirmed via A/B testing on different networks and with the same configuration, that this is due to the fact that Verizon Wireless blocks WebSocket connections, which has been reported elsewhere (see my comments on the original question).
This can be very tricky to diagnose. I hope it helps someone in the future!
Related
I'm a C++ developer and beginner in the Node world.
I would like to create a CEP and VUE based Photoshop plugin.
The skeleton plugin works well.
I would like to use node-libcurl package for this plugin.
I installed libcurl - It's OK.
npm i node-libcurl --save
I put down into my C4.js
const { curly } = require('node-libcurl');
When I want to build my project I got this error:
INFO Starting development server... 98% after emitting CopyPlugin
ERROR Failed to compile with 1 error
7:26:51 PM error in
./node_modules/node-libcurl/lib/binding/node_libcurl.node
Module parse failed: Unexpected character '�' (1:2)
You may need an appropriate loader to handle this file type, currently no loaders are
configured to process this file. See https://webpack.js.org/concepts#loaders (Source code omitted for > > this binary file)
# ./node_modules/node-libcurl/dist/Easy.js 5:17-60
# ./node_modules/node-libcurl/dist/index.js
# ./src/c4/C4.js
# ./src/main.js
# multi (webpack)-dev-server/client?http://192.168.1.22:8080&sockPath=/sockjs-node
(webpack)/hot/dev-server.js ./src/main.js
I tried this webpack.config.js in .... \node_modules\node-libcurl
module.exports = {
target: "node",
node: {
__dirname: false,
},
module: {
rules: [
{
test: /\.node$/,
loader: "node-loader",
},
],
},
};
... but it did not work.
I appreciate any help
Thx:
Carlos
It was my fail.
I got answer from developer.
This library is not supposed to work in the Browser, it is a backend-only library.
/Carlos
I am following a tutorial on how to create a colabrative document. The github is below. It uses ipfs for the P2P aspect.
https://github.com/ipfs-shipyard/shared-editing-demo
I am getting the following error:
Uncaught Error: no protocol with name: libp2p-webrtc-star
I have searched and found possible solutions e.g. changing the config found in the link below but it has not worked:
https://github.com/ipfs/js-ipfs/issues/1029
config: { // overload the default config
Addresses: {
Swarm: [
"/dns4/star-signal.cloud.ipfs.team/wss/p2p-webrtc-star"
],
API: '',
Gateway: ''
},
}
})
The above does not work as I still get the same error. There was a mention (on the github) of swarm having both the old and the new config together and that is why the error is being thrown. However, I am unsure how to resolve this.
i had that with 0.41.0 version. also try to use /dns4/ws-star.discovery.libp2p.io/tcp/443/wss/p2p-websocket-star
switch back to 0.40.0 worked for me
I'm trying to set up grunt with grunt-responsive-images, and getting the following error:
Warning: Could not execute GraphicsMagick/ImageMagick: gm "identify" "-ping" "-format" "%m:%T:%s" "assets/_img/bgAbout.jpg" this most likely means the gm/convert binaries can't be found
The npm and ImageMagick are both installed, have also tried GraphicsMagick (with default engine) to no avail.
I've verified all my versions of node/grunt/packages and I'm on Windows 10 if that's helpful info.
relevant bits from gruntfile.js:
responsive_images: {
dev: {
options: {
engine: 'im'
},
files: [{
expand: true,
src: ['**/*.{gif,jpg,png}'],
cwd: 'assets/_img/',
dest: 'assets/test/'
}]
}
},
grunt.loadNpmTasks('grunt-responsive-images');
grunt.registerTask('default', ['responsive_images']);
All relevant help I've found points to ImageMagick/GraphicsMagick not being installed, but it is. What could be hindering the communication between the task and IM?
Ugh. foiled by Windows UAC! Ran cmd as administrator, and it worked like a charm. Why did it take so long for my basic customer support troubleshooting reflexes of yore to kick in?
I have installed intern globally and on command prompt 'intern serve' commands works fine. However after adding reporters property in intern.js if I run 'intern serve' command then nothing happens and command stuck as below saying "Running runner tests…".
D:\start>intern serve
Running runner tests…
Here is my intern.js file
// Learn more about configuring this file at <https://theintern.github.io/intern/#configuration>.
// These default settings work OK for most people. The options that *must* be changed below are the packages, suites,
// excludeInstrumentation, and (if you want functional tests) functionalSuites
define({
// Default desired capabilities for all environments. Individual capabilities can be overridden by any of the
// specified browser environments in the `environments` array below as well. See
// <https://theintern.github.io/intern/#option-capabilities> for links to the different capabilities options for
// different services.
//
// Note that the `build` capability will be filled in with the current commit ID or build tag from the CI
// environment automatically
capabilities: {
'browserstack.selenium_version': '2.45.0'
},
// Browsers to run integration testing against. Options that will be permutated are browserName, version, platform,
// and platformVersion; any other capabilities options specified for an environment will be copied as-is. Note that
// browser and platform names, and version number formats, may differ between cloud testing systems.
environments: [
{ browserName: "chrome", platform: "WINDOWS" }
],
// Maximum number of simultaneous integration tests that should be executed on the remote WebDriver service
maxConcurrency: 2,
// Name of the tunnel class to use for WebDriver tests.
// See <https://theintern.github.io/intern/#option-tunnel> for built-in options
/*tunnel: 'BrowserStackTunnel',*/
// Configuration options for the module loader; any AMD configuration options supported by the AMD loader in use
// can be used here.
// If you want to use a different loader than the default loader, see
// <https://theintern.github.io/intern/#option-useLoader> for more information.
loaderOptions: {
// Packages that should be registered with the loader in each testing environment
packages: [
{ name: "dojo", location: "node_modules/dojo" },
{ name: "dojox", location: "node_modules/dojox" },
{ name: "dijit", location: "node_modules/dijit" },
{ name: "showcase", location: "dist/src/showcase" },
{ name: "common", location: "dist/src/common" },
{ name: "technical-topics", location: "dist/src/technical-topics" }
]
},
// Unit test suite(s) to run in each browser
suites: [ 'tests/**/*.js' ],
tunnel: 'NullTunnel',
// Functional test suite(s) to execute against each browser once unit tests are completed
functionalSuites: [ /* 'myPackage/tests/functional' */ ],
reporters: [
{ id: 'Runner', filename: 'tests/reporters/Runner/report.html' }
],
// A regular expression matching URLs to files that should not be included in code coverage analysis. Set to `true`
// to completely disable code coverage.
excludeInstrumentation: /^(?:tests|node_modules)\//
});
There are a several issues here:
The message "Running runner tests...' is only emitted by the Combined reporter, not the Runner reporter.
The Runner reporter is intended to output to the console; giving it an HTML filename will just output text to an HTML file (it won't generate an HTML report).
The reporter config doesn't actually do anything when you're running intern serve because intern in serve mode is just serving files (not running tests).
Is your intern.js file in tests\? Intern assumes the project directory looks like:
D:\start
tests\
intern.js
node_modules\
intern\
When running intern serve in D:\start, intern will look for its config file in tests\intern.js.
I am launching my Intern-based tests through the intern-runner script, like this:
<full_path>\intern\.bin\intern-runner config=unittest/intern
My unittest\intern.js configuration file contains the following:
define({
reporters: [ "junit", "console", "lcovhtml", "runner" ],
excludeInstrumentation: /(?:dojo|intern|istanbul|reporters|unittest)(?:\\|\/)/,
suites: [ "unittest/all_intern.js" ],
forDebug: console.log("Customized intern config for test runner loaded successfully!"),
loader: {
packages: [
{ name: 'resources', location: 'abc/resources' },
{ name: 'stats', location: 'abc/resources/stats' },
{ name: 'nls', location: 'abc/nls' },
{ name: 'widgets', location: 'abc/widgets' },
{ name: 'views', location: 'abc/views' },
]
},
useLoader: {
'host-browser': 'node_modules/dojo/dojo.js'
},
tunnel: 'NullTunnel',
useSauceConnect: false,
webdriver: {
host: 'localhost',
port: 4444
},
proxyUrl: "http://localhost:8010/",
environments: [
{
browserName: 'chrome'
}
]
});
Output to the terminal/command window looks hopeful:
Customized intern config for test runner loaded successfully!
Listening on 0.0.0.0:9000
Starting tunnel...
Initialised chrome 40.0.2214.111 on XP
And the Chrome browser is indeed launched, and I see my unittests running and passing in the browser contents. However, control never goes back to the terminal/command window--I don't see anything like "634/634 tests pass" or whatever, and I have to Ctrl+C to kill the intern-runner process. And of course, no code coverage files are generated. Is this due perhaps to my file structure? The Intern files are in a completely separate directory from these unit tests--I am not invoking intern-runner from a common parent directory for both Intern libraries and unit test files (and the product files they are testing).
I can create a diagram to illustrate the file/directory structure, if that is important. Note that I did change the Intern structure a bit, like:
<Dir_123>\intern\intern-2.2.2\bin\intern-runner.js
<Dir_123>\intern\intern-2.2.2\lib\<all_the_usual>
<Dir_123>\intern\intern-2.2.2\node_modules\<all_the_usual>
<Dir_123>\intern\.bin\intern-runner.cmd
i.e., what I had changed was to insert an extra "intern-2.2.2" directory after "intern", and the ".bin" directory containing intern-runner.cmd is a peer of "intern-2.2.2". Hope this is not confusing. :(
And note that the "proxyUrl" config property represents the URL that the unittest files and product files are available from the web server. Am I doing this right, by configuring the proxyUrl for this purpose? If I omit it, nothing runs because the default used is localhost:9000. I see in the "Configuring Intern" article on Github that proxyUrl is "the URL to the instrumentation proxy," but I don't really understand what that means.
It looks like you're making pretty good progress. Your directory structure is a bit non-standard (any particular reason for that?), but that shouldn't be a show-stopper. The problem you're seeing is probably due to a proxy misconfiguration. Intern is loading the test client and your unit tests, but the code in the browser is unable to communicate test results back to Intern.
As you mentioned, the proxyUrl parameter is the URL at which Intern's instrumenting proxy can be found. The "instrumenting proxy" is basically just an HTTP server than Intern runs to serve test files and to receive information from browsers under test. (It also instruments JS files as it serves them to gather code coverage data, hence the "instrumenting" part of the name.) By default, it's at localhost:9000. That means a browser under test running on localhost can GET or POST to localhost:9000 to talk to Intern.
You can also run Intern behind another server, like nginx, and have that server proxy requests to Intern. In that case, you need to 1) set Intern's proxyUrl to the address of the proxying server, and 2) setup proxying rules in the server to pass requests back to Intern at localhost:9000.
Intern also has a proxyPort parameter to control the port the instrumenting proxy serves on. The proxy listens at localhost:<proxyPort>, where proxyPort defaults to 9000. If tests are talking to Intern's proxy directly (with no intermediate nginx or Apache or anything), proxyPort will be the same as the port in proxyUrl. If an intermediate server is being used, the two can have different values.
When intern-runner runs unit tests, it tells the test browser to GET <proxyUrl>/client.html?config=.... Since you have some external server running and you've set proxyUrl to that server's address, that server will serve client.html and the other relevant Intern files, allowing the unit tests to run. However, when the unit tests are finished and the browser attempts to communicate this back to Intern at proxyUrl, it's going to fail unless you've configured the external server to proxy requests back to localhost:<proxyPort>.