Skip to content
This repository has been archived by the owner on Jan 30, 2023. It is now read-only.

Allow payload response to be a falsey but non-null or undefined value #126

Merged

Conversation

SteelBurgher
Copy link
Contributor

No description provided.

@alexlafroscia
Copy link
Collaborator

alexlafroscia commented Jun 28, 2016

Could you add a unit test instead of a component/integration test? I don't think there's a reason we need to invoke all of the component/DOM logic to verify that this works correctly... Unless I'm missing something.

I'd like to see a few test cases added, too: undefined, null, and some falsey value (like 0 that you picked) to make sure they all work like we expect.

@SteelBurgher
Copy link
Contributor Author

I totally agree. Good unit tests forthcoming.

@alexlafroscia
Copy link
Collaborator

Fantastic 👍

assert.equal(payloadWithFalseyNumber, 0);

const payloadWithNaN = service.handleResponse(200, {}, NaN);
assert.equal(isNaN(payloadWithNaN), true);
Copy link
Collaborator

Choose a reason for hiding this comment

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

You can just do this as assert.ok. Not a merge-blocker, just a note.

@SteelBurgher
Copy link
Contributor Author

I switched to using assert. what's with the appveyor build always failing?

@alexlafroscia
Copy link
Collaborator

I'm not sure. It's not just your build, all of the PRs are failing like this. Not sure if it's an Appveyor issue or a Windows issue... I'm going to get set up in a Windows VM tonight and see what's going on, because I'm not comfortable pulling this if there is actually an issue on Windows. Hold tight and we'll get this pulled in as soon as I know what's up there.

@alexlafroscia
Copy link
Collaborator

Actually, I just noticed that my PR from last night was fine on Appveyor.. Can you try rebasing off of the current master and pushing everything again? Maybe it was a problem with a dependency that is now updated.

@alexlafroscia
Copy link
Collaborator

It seems like the tests are passing again, on the current master branch. However, that branch moves the test runner over to Mocha instead of Qunit, so you'll have to update your tests. To save you the trouble, if you add me as a collaborator on your fork, I'll handle the rebase/test update and push a commit up to this PR so we can get this closed.

@SteelBurgher
Copy link
Contributor Author

I added you as a collaborator. Sorry was away for some time on a long vacation.

@alexlafroscia
Copy link
Collaborator

No worries 😄 I'll try to get this finished up today.

@alexlafroscia
Copy link
Collaborator

@SteelBurgher Can you check out my version of your branch over here? It should be exactly the same, but with the (same) tests written in Mocha and rebased off the current master. The tests fail, but that's problem on master right now too so don't worry about that. I just wanted to verify that it looks good to you, I didn't want to go ahead and push --force your branch.

@SteelBurgher
Copy link
Contributor Author

@alexlafroscia looks good, you can push.

@alexlafroscia alexlafroscia force-pushed the payload-checking-modification branch from cb48094 to 3011250 Compare July 29, 2016 21:39
@alexlafroscia alexlafroscia merged commit b2eb109 into ember-cli:master Jul 29, 2016
@alexlafroscia alexlafroscia deleted the payload-checking-modification branch July 29, 2016 21:39
@alexlafroscia
Copy link
Collaborator

Test are failing but it's due to this Ember bug so I'm not worried about it.

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

Successfully merging this pull request may close these issues.

2 participants