Skip to content

Conversation

@BillyAbildgaard
Copy link

resolves https://github.com/RackHD/RackHD/issues/259

The actual fix for the bug was the line I added to the swagger_render. @zyoung51 helped me find that fix.

@RackHD/corecommitters @dalebremner @srinia6 @brianparry

@JenkinsRHD
Copy link
Contributor

*** BUILD #1603 ***

@BillyAbildgaard
Copy link
Author

test this please

@srinia6
Copy link
Contributor

srinia6 commented Jun 29, 2016

+1

@BillyAbildgaard
Copy link
Author

@yyscamper not sure if you want to take a look at this fix since it addresses github issue RackHD/RackHD#259 that you worked on

var _ = injector.get('_');

module.exports = function create(fittingDef) {
injector = require('../../index.js').injector;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

line #5 has the same code, what's the difference? Could you please explain more why this is the root case?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The difference is in workflows we are using simpleWrapper to mock an injectable and what's happening is the swagger_render takes this injectable and exports the function with it. The Profiles test then continues to use this "stale" injectable.
By adding in this line we are essentially refreshing the injectable to make sure if there were any changes the exported function takes them into account.

@zyoung51 can correct me if my understanding is wrong or if he wants to add more :)

Copy link
Contributor

@yyscamper yyscamper Jun 30, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I know the require has cache (see https://nodejs.org/api/modules.html#modules_caching), so the two require operation should return the same object, I think this line will not refresh the injector

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yyscamper This change is a work-around for an issue with the way mocking is being done. Without this line, the http server will run with an old version of the injector that still has mocks from the previous test. We have work planned to make structural changes to all of the unit tests to avoid the need for this work-around in the future.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brianparry : thanks for your explanation. I just wondering how this line of code works, because of the require caching, normally you should not get a new version of injector. But depends on your testing, this should work. Maybe some of my understanding is not correct.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yyscamper I'm not entirely sure why this works. For some reason there is a difference in the injector object between initially requiring the fitting and loading the fitting. Given that this is a temporary work-around for a test-only problem, I think it's acceptable for now.

@yyscamper
Copy link
Contributor

yyscamper commented Jun 30, 2016

@BillyAbildgaard thanks for your fix. Could you please clarify my above questions? and also the following question:
Do you have run the unit-test files in random order with enough times? Because the issue you fixed may not be reproduced in a few tries.

@BillyAbildgaard
Copy link
Author

@yyscamper I ran the tests in general and ran the specific case you saw where running workflows before profiles caused the failure. The fix eliminated this case.

This story was just to fix the bug. Stryker team has an additional story in our backlog to look into running the unit tests randomly

@yyscamper
Copy link
Contributor

@BillyAbildgaard : The whole solution of random unit-test will need relative much consideration, but if you want to try, so can simplify use sort -R, the full command is:

./node_modules/.bin/mocha $(find spec -name '*-spec.js' | sort -R ) -R spec --require spec/helper.js

Could you please try above random testing with enough times? Because I think that issue should not be considered as fully resolved if the random testing fails.

@BillyAbildgaard
Copy link
Author

@yyscamper I can confirm the fix does resolve the bug that was reported. I tested it multiple times.

We have a story for randomized testing, but that was outside the scope of what I was trying to do for this, which was just to resolve the bug reported in RackHD/RackHD#259.

@brianparry
Copy link
Contributor

@yyscamper As @BillyAbildgaard has mentioned, this PR is a general cleanup of unit test mocking and a fix for RackHD/RackHD#259. Full random-order testing support is planned as part of a future story and is outside the scope of this PR.

configuration = helper.injector.get('Services.Configuration');
sinon.stub(configuration, 'set').returns(configuration);
sinon.stub(configuration, 'getAll').returns({});
this.timeout(10000);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this test fail consistently without the longer timeout?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brianparry not that I saw, but I figured I would just increase the timeout since I was in there to decrease the likelihood of a failure because of a timeout.

@yyscamper
Copy link
Contributor

@BillyAbildgaard @brianparry : I agree on the scope for this PR. So if there is any more unit-test error if run in random order, we can fix it then.

@brianparry brianparry merged commit d7f1c88 into RackHD:master Jun 30, 2016
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

Successfully merging this pull request may close these issues.

5 participants