Skip to content

'gopherjs test' always fails tests #624

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
emidoots opened this issue Apr 16, 2017 · 6 comments
Closed

'gopherjs test' always fails tests #624

emidoots opened this issue Apr 16, 2017 · 6 comments

Comments

@emidoots
Copy link

With a simple test like:

package example

import "testing"

func TestExample(t *testing.T) {

}

It will always fail when ran via gopherjs test:

gopherjs: Source maps disabled. Use Node.js 4.x with source-map-support module for nice stack traces.
PASS
fatal error: all goroutines are asleep - deadlock!
FAIL	github.com/gopherjs/vecty/example	0.344s

I'm wondering if this is a known issue / people are not using gopherjs test, or if it's potentially something configured incorrectly on my system.

  • Using gopherjs version 3496c6f
  • node --version reports v7.9.0 (the latest available via brew)
@dmitshur
Copy link
Member

dmitshur commented Apr 16, 2017

Is that the only test you have, or are there more?

It should definitely work.

I'm guessing you don't have system call module installed, do you?

https://github.com/gopherjs/gopherjs/blob/master/doc/syscalls.md

It's possible something we changed more recently has made it required for tests to run, or perhaps it's always been that way. I don't know, because I always have it installed, and gopherjs test works for me. It'd be nice to document this though.

@dmitshur
Copy link
Member

For reference, this is what my output is:

$ gopherjs test
PASS
ok  	_/Users/Dmitri/Dropbox/Work/2013/GoLand/src/github.com/shurcooL/play/31	0.458s
$ gopherjs test -v
=== RUN   TestExample
--- PASS: TestExample (0.00s)
PASS
ok  	_/Users/Dmitri/Dropbox/Work/2013/GoLand/src/github.com/shurcooL/play/31	0.469s
$ 

(I'm not sure why it's printing the full path instead of import paths though...)

@emidoots
Copy link
Author

Is that the only test you have, or are there more?

Correct, just that test. No more.

I'm guessing you don't have system call module installed, do you?

Ok, I gave that a shot and it fixed it. My output is now:

$ gopherjs test
gopherjs: Source maps disabled. Use Node.js 4.x with source-map-support module for nice stack traces.
PASS
ok  	github.com/gopherjs/vecty/example	0.326s
$ gopherjs test -v
gopherjs: Source maps disabled. Use Node.js 4.x with source-map-support module for nice stack traces.
=== RUN   TestExample
--- PASS: TestExample (0.00s)
PASS
ok  	github.com/gopherjs/vecty/example	0.334s

I don't know why I still get the Node.js 4.x warning when my node --version reports v7.9.0 though.

I'm almost certain gopherjs test worked previously without installing the syscall module (I have never installed it in the past AFAIK). So probably a regression, would be my bet.

@dmitshur
Copy link
Member

dmitshur commented Apr 17, 2017

I'm almost certain gopherjs test worked previously without installing the syscall module (I have never installed it in the past AFAIK). So probably a regression, would be my bet.

We should document this new requirement. It might be worth it to investigate if it's avoidable. The new requirement might be due to recent enhancements, and so it may be unavoidable. Filed #626 for that.


I don't know why I still get the Node.js 4.x warning when my node --version reports v7.9.0 though.

Well, that's a fail on the warning message text. Filed #627 to improve the text. The issue is you need source-map-support module installed. Here, I've highlighted the important part you're missing:

gopherjs: Source maps disabled. Use Node.js 4.x with source-map-support module for nice stack traces.

See the 3rd paragraph of https://github.com/gopherjs/gopherjs/#installation-and-usage for installation instructions of source-map-support module.

@dmitshur
Copy link
Member

This issue forked into #627, which is already resolved, and #626, which is tracking the specific task there.

It looks like everything here is done, so we can close this, correct? /cc @slimsag

@emidoots
Copy link
Author

sgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants