Does expect(…).toBe resolve promises or do I need to wait for them?
Protractor testing is hard and confusing (at least for me).
I have the following
`SomeTestFile.spec.ts`
describe('A test: ', () => {
beforeEach(() => {
....
}
it ('Should validate a label', async() => {
await helper.validateALabel(label);
}
....
}
Then in the helper class:
helper.ts
export class Helper {
....
public validateLabel(label: String): Promise<void> {
expect(label).toBe('This is the string of the label');
}
....
}
So the question is do I need to await the expect(label).toBe(...)?
Should it be
await expect(label).toBe(...)
OR is this just fine (and if so why do I keep getting Unandled Promise Rejection Warnings)?
expect(label).toBe(...)
angular typescript protractor asked Nov 23 '18 at 4:18
BorisBoris
558
add a comment |
Protractor testing is hard and confusing (at least for me).
I have the following
`SomeTestFile.spec.ts`
describe('A test: ', () => {
beforeEach(() => {
....
}
it ('Should validate a label', async() => {
await helper.validateALabel(label);
}
....
}
Then in the helper class:
helper.ts
export class Helper {
....
public validateLabel(label: String): Promise<void> {
expect(label).toBe('This is the string of the label');
}
....
}
So the question is do I need to await the expect(label).toBe(...)?
Should it be
await expect(label).toBe(...)
OR is this just fine (and if so why do I keep getting Unandled Promise Rejection Warnings)?
expect(label).toBe(...)
asked Nov 23 '18 at 4:18
BorisBoris
558
It is recommended to useawaitfor expect statements
– Madhan
Nov 23 '18 at 5:35
You can await your promise and use expect without await. If you use expect on a promise thentoBearg would have to be the promise you're comparing to
– BrunoLM
Nov 23 '18 at 6:12
add a comment |
Protractor testing is hard and confusing (at least for me).
I have the following
`SomeTestFile.spec.ts`
describe('A test: ', () => {
beforeEach(() => {
....
}
it ('Should validate a label', async() => {
await helper.validateALabel(label);
}
....
}
Then in the helper class:
helper.ts
export class Helper {
....
public validateLabel(label: String): Promise<void> {
expect(label).toBe('This is the string of the label');
}
....
}
So the question is do I need to await the expect(label).toBe(...)?
Should it be
await expect(label).toBe(...)
OR is this just fine (and if so why do I keep getting Unandled Promise Rejection Warnings)?
expect(label).toBe(...)
asked Nov 23 '18 at 4:18
BorisBoris
558
Protractor testing is hard and confusing (at least for me).
I have the following
`SomeTestFile.spec.ts`
describe('A test: ', () => {
beforeEach(() => {
....
}
it ('Should validate a label', async() => {
await helper.validateALabel(label);
}
....
}
Then in the helper class:
helper.ts
export class Helper {
....
public validateLabel(label: String): Promise<void> {
expect(label).toBe('This is the string of the label');
}
....
}
So the question is do I need to await the expect(label).toBe(...)?
Should it be
await expect(label).toBe(...)
OR is this just fine (and if so why do I keep getting Unandled Promise Rejection Warnings)?
expect(label).toBe(...)
asked Nov 23 '18 at 4:18
BorisBoris
558
asked Nov 23 '18 at 4:18
BorisBoris
558
asked Nov 23 '18 at 4:18
BorisBoris
558
asked Nov 23 '18 at 4:18
BorisBoris
558
asked Nov 23 '18 at 4:18
BorisBoris
558
558
It is recommended to useawaitfor expect statements
– Madhan
Nov 23 '18 at 5:35
You can await your promise and use expect without await. If you use expect on a promise thentoBearg would have to be the promise you're comparing to
– BrunoLM
Nov 23 '18 at 6:12
add a comment |
It is recommended to useawaitfor expect statements
– Madhan
Nov 23 '18 at 5:35
You can await your promise and use expect without await. If you use expect on a promise thentoBearg would have to be the promise you're comparing to
– BrunoLM
Nov 23 '18 at 6:12
It is recommended to use
await for expect statements– Madhan
Nov 23 '18 at 5:35
It is recommended to use
await for expect statements– Madhan
Nov 23 '18 at 5:35
You can await your promise and use expect without await. If you use expect on a promise then
toBe arg would have to be the promise you're comparing to– BrunoLM
Nov 23 '18 at 6:12
You can await your promise and use expect without await. If you use expect on a promise then
toBe arg would have to be the promise you're comparing to– BrunoLM
Nov 23 '18 at 6:12
add a comment |
2 Answers
2
active
oldest
votes
It is a good practice to use expects in the step definitions. You can resolve the value from the helper class and in your step definitions you can make some assertions and make the test step pass or fail.
`SomeTestFile.spec.ts`
describe('A test: ', () => {
beforeEach(() => {
....
}
it ('Should validate a label', async() => {
await expect(helper.validateALabel(label)).toBe('This is the string of the label');
}
....
}
helper.ts
export class Helper {
....
function validateLabel(label) {
return new Promise((resolve, reject) => {
return resolve('This is the string of the label');
})
}
....
}
answered Nov 23 '18 at 5:49
Bharath Kumar SBharath Kumar S
5541420
add a comment |
It doesn't.
You have to await your promise and compare the result.
// example promise function
const validateALabel = (label) => new Promise(r => r(true))
it ('validates a label', async () => {
const valid = await validateALabel(label)
expect(valid).toBeTruthy()
})
In you case it seems you are defining the wrong return type here:
public validateLabel(label: String): Promise<void> {
expect(label).toBe('This is the string of the label');
}
This actually doesn't return a Promise<void>, but just void, so you don't need async/await at all
answered Nov 23 '18 at 6:14
BrunoLMBrunoLM
61k67229391
Right, so IntelliJ tells me that .toBe(..) returns a Promise<void>. Yet the interface defines it as if it returns a boolean (with the documentation specifying a return value of {}). See here: imgur.com/a/TNcXayB And then secondly, maybe this is bad practice and why it has happened to me a few times, I have used expect in a helper class (so not in the 'it..' block but in another file) and any verification has failed to process (so things that should fail simply don't).
– Boris
Nov 23 '18 at 7:18
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53440601%2fdoes-expect-tobe-resolve-promises-or-do-i-need-to-wait-for-them%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It is a good practice to use expects in the step definitions. You can resolve the value from the helper class and in your step definitions you can make some assertions and make the test step pass or fail.
`SomeTestFile.spec.ts`
describe('A test: ', () => {
beforeEach(() => {
....
}
it ('Should validate a label', async() => {
await expect(helper.validateALabel(label)).toBe('This is the string of the label');
}
....
}
helper.ts
export class Helper {
....
function validateLabel(label) {
return new Promise((resolve, reject) => {
return resolve('This is the string of the label');
})
}
....
}
answered Nov 23 '18 at 5:49
Bharath Kumar SBharath Kumar S
5541420
add a comment |
It is a good practice to use expects in the step definitions. You can resolve the value from the helper class and in your step definitions you can make some assertions and make the test step pass or fail.
`SomeTestFile.spec.ts`
describe('A test: ', () => {
beforeEach(() => {
....
}
it ('Should validate a label', async() => {
await expect(helper.validateALabel(label)).toBe('This is the string of the label');
}
....
}
helper.ts
export class Helper {
....
function validateLabel(label) {
return new Promise((resolve, reject) => {
return resolve('This is the string of the label');
})
}
....
}
answered Nov 23 '18 at 5:49
Bharath Kumar SBharath Kumar S
5541420
add a comment |
It is a good practice to use expects in the step definitions. You can resolve the value from the helper class and in your step definitions you can make some assertions and make the test step pass or fail.
`SomeTestFile.spec.ts`
describe('A test: ', () => {
beforeEach(() => {
....
}
it ('Should validate a label', async() => {
await expect(helper.validateALabel(label)).toBe('This is the string of the label');
}
....
}
helper.ts
export class Helper {
....
function validateLabel(label) {
return new Promise((resolve, reject) => {
return resolve('This is the string of the label');
})
}
....
}
answered Nov 23 '18 at 5:49
Bharath Kumar SBharath Kumar S
5541420
It is a good practice to use expects in the step definitions. You can resolve the value from the helper class and in your step definitions you can make some assertions and make the test step pass or fail.
`SomeTestFile.spec.ts`
describe('A test: ', () => {
beforeEach(() => {
....
}
it ('Should validate a label', async() => {
await expect(helper.validateALabel(label)).toBe('This is the string of the label');
}
....
}
helper.ts
export class Helper {
....
function validateLabel(label) {
return new Promise((resolve, reject) => {
return resolve('This is the string of the label');
})
}
....
}
answered Nov 23 '18 at 5:49
Bharath Kumar SBharath Kumar S
5541420
edited Nov 23 '18 at 6:08
answered Nov 23 '18 at 5:49
Bharath Kumar SBharath Kumar S
5541420
answered Nov 23 '18 at 5:49
Bharath Kumar SBharath Kumar S
5541420
answered Nov 23 '18 at 5:49
Bharath Kumar SBharath Kumar S
5541420
5541420
add a comment |
add a comment |
It doesn't.
You have to await your promise and compare the result.
// example promise function
const validateALabel = (label) => new Promise(r => r(true))
it ('validates a label', async () => {
const valid = await validateALabel(label)
expect(valid).toBeTruthy()
})
In you case it seems you are defining the wrong return type here:
public validateLabel(label: String): Promise<void> {
expect(label).toBe('This is the string of the label');
}
This actually doesn't return a Promise<void>, but just void, so you don't need async/await at all
answered Nov 23 '18 at 6:14
BrunoLMBrunoLM
61k67229391
Right, so IntelliJ tells me that .toBe(..) returns a Promise<void>. Yet the interface defines it as if it returns a boolean (with the documentation specifying a return value of {}). See here: imgur.com/a/TNcXayB And then secondly, maybe this is bad practice and why it has happened to me a few times, I have used expect in a helper class (so not in the 'it..' block but in another file) and any verification has failed to process (so things that should fail simply don't).
– Boris
Nov 23 '18 at 7:18
add a comment |
It doesn't.
You have to await your promise and compare the result.
// example promise function
const validateALabel = (label) => new Promise(r => r(true))
it ('validates a label', async () => {
const valid = await validateALabel(label)
expect(valid).toBeTruthy()
})
In you case it seems you are defining the wrong return type here:
public validateLabel(label: String): Promise<void> {
expect(label).toBe('This is the string of the label');
}
This actually doesn't return a Promise<void>, but just void, so you don't need async/await at all
answered Nov 23 '18 at 6:14
BrunoLMBrunoLM
61k67229391
Right, so IntelliJ tells me that .toBe(..) returns a Promise<void>. Yet the interface defines it as if it returns a boolean (with the documentation specifying a return value of {}). See here: imgur.com/a/TNcXayB And then secondly, maybe this is bad practice and why it has happened to me a few times, I have used expect in a helper class (so not in the 'it..' block but in another file) and any verification has failed to process (so things that should fail simply don't).
– Boris
Nov 23 '18 at 7:18
add a comment |
It doesn't.
You have to await your promise and compare the result.
// example promise function
const validateALabel = (label) => new Promise(r => r(true))
it ('validates a label', async () => {
const valid = await validateALabel(label)
expect(valid).toBeTruthy()
})
In you case it seems you are defining the wrong return type here:
public validateLabel(label: String): Promise<void> {
expect(label).toBe('This is the string of the label');
}
This actually doesn't return a Promise<void>, but just void, so you don't need async/await at all
answered Nov 23 '18 at 6:14
BrunoLMBrunoLM
61k67229391
It doesn't.
You have to await your promise and compare the result.
// example promise function
const validateALabel = (label) => new Promise(r => r(true))
it ('validates a label', async () => {
const valid = await validateALabel(label)
expect(valid).toBeTruthy()
})
In you case it seems you are defining the wrong return type here:
public validateLabel(label: String): Promise<void> {
expect(label).toBe('This is the string of the label');
}
This actually doesn't return a Promise<void>, but just void, so you don't need async/await at all
answered Nov 23 '18 at 6:14
BrunoLMBrunoLM
61k67229391
answered Nov 23 '18 at 6:14
BrunoLMBrunoLM
61k67229391
answered Nov 23 '18 at 6:14
BrunoLMBrunoLM
61k67229391
answered Nov 23 '18 at 6:14
BrunoLMBrunoLM
61k67229391
61k67229391
Right, so IntelliJ tells me that .toBe(..) returns a Promise<void>. Yet the interface defines it as if it returns a boolean (with the documentation specifying a return value of {}). See here: imgur.com/a/TNcXayB And then secondly, maybe this is bad practice and why it has happened to me a few times, I have used expect in a helper class (so not in the 'it..' block but in another file) and any verification has failed to process (so things that should fail simply don't).
– Boris
Nov 23 '18 at 7:18
add a comment |
Right, so IntelliJ tells me that .toBe(..) returns a Promise<void>. Yet the interface defines it as if it returns a boolean (with the documentation specifying a return value of {}). See here: imgur.com/a/TNcXayB And then secondly, maybe this is bad practice and why it has happened to me a few times, I have used expect in a helper class (so not in the 'it..' block but in another file) and any verification has failed to process (so things that should fail simply don't).
– Boris
Nov 23 '18 at 7:18
Right, so IntelliJ tells me that .toBe(..) returns a Promise<void>. Yet the interface defines it as if it returns a boolean (with the documentation specifying a return value of {}). See here: imgur.com/a/TNcXayB And then secondly, maybe this is bad practice and why it has happened to me a few times, I have used expect in a helper class (so not in the 'it..' block but in another file) and any verification has failed to process (so things that should fail simply don't).
– Boris
Nov 23 '18 at 7:18
Right, so IntelliJ tells me that .toBe(..) returns a Promise<void>. Yet the interface defines it as if it returns a boolean (with the documentation specifying a return value of {}). See here: imgur.com/a/TNcXayB And then secondly, maybe this is bad practice and why it has happened to me a few times, I have used expect in a helper class (so not in the 'it..' block but in another file) and any verification has failed to process (so things that should fail simply don't).
– Boris
Nov 23 '18 at 7:18
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53440601%2fdoes-expect-tobe-resolve-promises-or-do-i-need-to-wait-for-them%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
It is recommended to use
awaitfor expect statements– Madhan
Nov 23 '18 at 5:35
You can await your promise and use expect without await. If you use expect on a promise then
toBearg would have to be the promise you're comparing to– BrunoLM
Nov 23 '18 at 6:12