It still takes 5 sec. for it to actually exit, but at least it does not keep running anymore.
With coverage enabled, it actually takes much longer, and the CPU goes up. So it looks like it still tries to calculate the coverage.
With coverage enabled, it actually takes much longer, and the CPU goes up. So it looks like it still tries to calculate the coverage.
FYI: I took another look at Babel and the problems we had with not-inline source maps. Looks like this is a known bug: babel/babel#5261.
Fortunately it also lists a workaround. So that means stripping the sourceMaps run-time will not be needed after all.
Fortunately it also lists a workaround. So that means stripping the sourceMaps run-time will not be needed after all.
Do you recognize this message:
SyntaxError: Unexpected token h in JSON at position 0
at JSON.parse @ anonymous
@ src\lib\ProxiedSession.ts:152:29
@ node_modules\@theintern\common\index.js:16:7174
at process._tickCallback @ internal\process\next_tick.js:68:7
at Command._callSessionMethod @ node_modules\src\Command.ts:811:11
at Command.quit @ node_modules\src\Command.ts:1561:16
at Suite.after @ src\lib\executors\Node.ts:565:28
@ src\lib\Suite.ts:434:54
at new e @ node_modules\@theintern\common\index.js:16:5068
at runLifecycleMethod @ src\lib\Suite.ts:399:13
at after @ src\lib\Suite.ts:507:13
@ src\lib\Suite.ts:719:47
@ node_modules\@theintern\common\index.js:16:6889
@ node_modules\@theintern\common\index.js:16:7174This happens every now and then (on BrowserStack and IE11)
It means that whatever it got wasn't valid JSON. Possibly the raw selenium log from BS would show more information.
That error should also ideally be showing some part of the invalid data.
Coverage data is collected by default unless
coverage is set to false. You shouldn't be getting an error in any case, though -- if there was no coverage data available, the request shouldn't return any. Try setting coverage: false in your config. If you happen to see what data cause the error, that would be useful to know so we could fix the underlying issue.
The raw selenium logs does not seem to show anything suspicious:
13:04:29.538 DEBUG [WebDriverServlet.handle] - Found handler: fef00a61-78c4-43a9-97df-11ba3c1b0a0e (org.openqa.selenium.ie.InternetExplorerDriverService)
13:04:29.538 DEBUG [WebDriverServlet.lambda$handle$3] - Handler thread for session fef00a61-78c4-43a9-97df-11ba3c1b0a0e (internet explorer): Executing POST on /session/fef00a61-78c4-43a9-97df-11ba3c1b0a0e/execute (handler: ServicedSession)
13:04:29.540 DEBUG [Passthrough.handle] - To upstream: {"script":"return (function getCoverageData(coverageVariable) {\n var coverageData = (function () {\n return this;\n })()[coverageVariable];\n return coverageData && JSON.stringify(coverageData);\n }).apply(this, arguments);","args":["__coverage__"]}
13:04:29.540 DEBUG [HttpURLConnection.writeRequests] - sun.net.www.MessageHeader@c2cff515 pairs: {POST /session/fef00a61-78c4-43a9-97df-11ba3c1b0a0e/execute HTTP/1.1: null}{Authorization: Basic cnV1ZGdyYXZlc3RlaWpuMTpGMXBReFRIYnk3d3hCZVBkc21IUw==}{Accept: application/json,text/plain;q=0.9}{X-Forwarded-Host: hub.browserstack.com}{User-Agent: axios/0.19.2}{X-Forwarded-For: 194.171.252.100}{x-connid: 21621292158}{BStack-Host: 185.44.130.87}{x-conn: keep-alive}{Content-Type: application/json; charset=utf-8}{Connection: close}{Cache-Control: no-cache}{Pragma: no-cache}{Host: localhost:64856}{Content-Length: 285}
13:04:29.610 DEBUG [HttpURLConnection.getInputStream0] - sun.net.www.MessageHeader@1b0da276 pairs: {null: HTTP/1.1 200 OK}{Content-Length: 77}{Content-Type: application/json; charset=UTF-8}{Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept}{Accept-Ranges: bytes}{Connection: close}
13:04:29.611 DEBUG [Passthrough.handle] - To downstream: {"sessionId":"fef00a61-78c4-43a9-97df-11ba3c1b0a0e","status":0,"value":null}
Even with
coverage: false I get this error:19:35:11 SyntaxError: Unexpected token E in JSON at position 26
19:35:11 at Server.get @ node_modules\src\Server.ts:376:16
19:35:11 at runRequest @ node_modules\src\Session.ts:133:12
19:35:11 @ node_modules\src\Session.ts:167:44
19:35:11 at new e @ node_modules\@theintern\common\index.js:16:5068
Any other ideas?
@jason0x43 any idea what I'm doing wrong here?
it("should emit an event on create", function () {
const { resolve } = this.async();
articles.events.on("create", () => resolve());
articles.create({ title: "win" });
});articles.create asynchronously emits a create event, so I'm essentially just trying to assert that the event is emitted. However, I get what appears to be an Intern error, saying Cannot read property '_resolver' of undefined.
The return value of this.async is a Deferred object, so it shouldn't be destructured.
const dfd = this.async();
articles.events.on("create", () => dfd.resolve());You can also use a Promise:
it("should emit an event on create", function () {
return new Promise(resolve => {
articles.events.on("create", resolve);
articles.create({ title: "win" });
});
});this should be fine since you're using a function declaration for your test, but Tests are also passed the current Test object to support arrow function test callbacks (where this isn't applicable), so you can doit("should emit an event on create", function (test) {
const dfd = test.async();
Promises are generally simpler unless you need some of Deferred's more complex behaviors, though.
Any suggestions on how I could write a TypeScript test that's compiled, but not executed? Here's my workaround for the time being:
describe("library", () => {
it("should compile without errors", () => {
// Note: This is not executed, only compiled for type-checking.
() => {
const n: number = "";
};
});
});
@GARMBoshouwers you'd set the coverage variable in the same way as for unit tests, and you would need to load your test pages through Intern's test server (e.g. localhost:9000). Coverage requires source files to be instrumented, and instrumentation for browser tests happens when files are served by the test server.
@rhpijnacker Not currently; time is only recorded for the test itself. I can see that being a useful stat to collect, though.
Every now and then, the BrowserStack run on IE11 does not put the window full-screen. I'm passing
"resolution": "1280x1024" to the environment, but nothing else. Do I need some extra setting to get the window maximized?
Adding timing for before/after each probably wouldn't be difficult, although how it gets collected and reported would need some thought. Like, should Intern remember the time for each
beforeEach call, or should it average them for a suite? Should those results be kept as Suite properties, or should Intern just include that info in events emitted when a beforeEach (afterEach, etc) finishes?
Hi, I have a custom reporter that listens to the testEnd event for some functional tests
@eventHandler()
testEnd(test: Test) {but on running, this event seems to get fired during initialisation before the browser even loads (it also hits after an actual test when I would expect it)
Is this as expected behaviour?