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
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(...)
angular typescript protractor
It is recommended to useawait
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 thentoBe
arg 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(...)
angular typescript protractor
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
angular typescript protractor
asked Nov 23 '18 at 4:18
Boris
557
557
It is recommended to useawait
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 thentoBe
arg would have to be the promise you're comparing to
– BrunoLM
Nov 23 '18 at 6:12
add a comment |
It is recommended to useawait
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 thentoBe
arg 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');
})
}
....
}
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
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');
})
}
....
}
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');
})
}
....
}
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');
})
}
....
}
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');
})
}
....
}
edited Nov 23 '18 at 6:08
answered Nov 23 '18 at 5:49
Bharath Kumar S
582317
582317
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
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
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
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
BrunoLM
59.5k66222383
59.5k66222383
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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
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