-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
WIP: Safer tests #1946
WIP: Safer tests #1946
Conversation
hey @rmg @bajtos I test on one linux vm and manage to reproduce 4 errors.
I fixed them by removing strong-remoting under dependant loopback-connector-remote's folder. When I clone loopback from github and npm install it, loopback-connector-remote installs strong-remoting 2.24.5 automatically under its node_modules folder which causes the failure. I am not sure are they necessarily installed as nested modules of loopback-connector-remote, but from the version number they look old and npm test could pass after I remove them :) Error details:
|
@jannyHou thank you for the investigation and a detailed report. loopback-connector-remote depends on strong-remoting (and loopback-datasource-juggler) because it uses some of the code/functionality provided by these modules. We were aware that juggler is designed as a singleton (i.e. there should be only one instance of the module in the dependency tree), there is a task to fix it - strongloop/loopback-connector-remote#5 I am quite surprised that strong-remoting suffers from the same problem too. We need to investigate this more to better understand why two instances of strong-remoting don't work well. Here is the reason why this problem is not observed on the 2.x branch: because both |
I identified the problem. strong-remoting has a global registry of @jannyHou fixing this problem is non-trivial, I'll work on this myself - see strongloop/loopback-connector-remote#34 |
@slnode test please |
strongloop/loopback-connector-remote#34 has been landed, let's check how CI likes that |
@@ -1,4 +1,4 @@ | |||
# LoopBack | |||
# LoopBack1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a type/forgotten change, please remove.
If the supertest request fails its basic assertions, there may not even be a body to perform checks against, so bail early when possible.
@slnode test please |
@slnode test please |
So the pr for "content type" is fine, the error comes from endpoint itself
Detailed error information with
|
To me, it looks like there is an issue with supertest. I have seen this issue pop up before although I can't remember exactly how it gets resolved. I'm guessing there is an issue booting up the server somewhere. In the past I've seen that for whatever reason, supertest does not "stop" the app instance properly, which would explain why the test is attempted multiple time, and why it passes on it's own but not with the other tests. I'm not familiar with supertest but if @rmg or @bajtos are, maybe you could explain this? In the meantime, I will look into supertest and try to figure out what's going on. |
@richardpringle thanks! It makes sense why there are duplicate failures. Yesterday I searched 'Cannot read property 'currentRetry' of undefined' but got few result, while now it's pretty clear. I will look into supertest and see how to solve the conflict. Update: A testing list as this one could pass on all systems. But running For example, test case 'includes loopback.token when necessary'(the first error) will return 401 instead of 200, but when I debug it the @bajtos could you give me some clue about why there is a conflict here? Is it caused by running multiple apps async and expose them to REST? Thanks! Error details:
|
Related: #2034 |
@bajtos thank you! |
I started cleaning up the tests in order to debug the windows failures, but haven't had time to finish yet.
@superkhau and @jannyHou have each contacted me separately about the failures, so I'm opening this PR to get more eyes.