Skip to content
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

Failing tests (with a clean install of three.js dev) #13606

Closed
levilime opened this issue Mar 15, 2018 · 6 comments
Closed

Failing tests (with a clean install of three.js dev) #13606

levilime opened this issue Mar 15, 2018 · 6 comments
Labels

Comments

@levilime
Copy link
Contributor

levilime commented Mar 15, 2018

Some failing tests in a clean install of three.js dev branch

In my local version of the current three.js (eb8f846) five tests fail. Two of these only fail when using the QUnit browser GUI that is generated in test/unit/UnitTests.html when doing npm run build-test.

problem

The three remaining also fail when doing npm run test. They are the following:
euler

I think these three tests fail relating to a issue with the behavior of assert.step in Qunit as highlighted here: qunitjs/qunit#1226 . It shows that counting the assert steps is not completely transparent from a test writing perspective.

The other two failing tests only happen in the browser GUI and are these:
failsonlyinbrowser

Because they work when running npm run test they are less of a priority to fix.

I wonder if it is interesting to fix these, although it seems from previous discussion that they seem to still work for some developers.

To reproduce I suggest to create a clean version of the code base with a clean npm install.

I run npm 5.6.0 and have the windows 10 operating system.

@levilime
Copy link
Contributor Author

levilime commented Mar 15, 2018

In #13607 I made a proof of concept to correct one of the three failing tests. Hope to hear whether this is a goose chase or that this is something worthwhile to pursue further for the other failing tests.

Thanks!

@Mugen87
Copy link
Collaborator

Mugen87 commented Mar 21, 2018

What about the remaining two fails? You've mentioned they happen only in the browser, right? Can you please run the test for BufferGeometry.fromDirectGeometry() and check if the corresponding model loads (examples/models/skinned/simple/simple.js)? Maybe you receive a timeout because the model could not loaded for some reasons...

@levilime
Copy link
Contributor Author

Hey @Mugen87. The model could not be downloaded due to CORS being disallowed for the examples/models/skinned/simple/simple.js resource.

cors

Funnily enough when searching this problem from a two link process from stack-overflow back to three.js, running things locally is made. On this three.js page the following suggestions are made:

  • change browser security.
  • serve files from a local web server and link to those.

Either choice might go hand in hand with some README text to setup testing. An other funny way would be to link the file served by three.js domain itself. But then the test will be dependent on an internet connection.

What do you think the best option is?

Hope to hear back from you!
Levi

@looeee
Copy link
Collaborator

looeee commented Mar 26, 2018

@levilime this is not so much a failing of the tests as a failing of the way you've set up your testing environment - every web app that loads files locally would fail in the exact same way in this case.

A README.md file for the tests is not a bad idea though, it could link to the how to run things locally page.

@Mugen87
Copy link
Collaborator

Mugen87 commented Mar 28, 2018

Good idea. I'll make a PR.

@levilime
Copy link
Contributor Author

Nice, good work 😄

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

No branches or pull requests

4 participants