Does expect(…).toBe resolve promises or do I need to wait for them?












0














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(...)









share|improve this question






















  • 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
















0














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(...)









share|improve this question






















  • 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














0












0








0







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(...)









share|improve this question













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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 23 '18 at 4:18









Boris

557




557












  • 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


















  • 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
















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












2 Answers
2






active

oldest

votes


















1














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');
})
}

....
}





share|improve this answer































    1














    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






    share|improve this answer





















    • 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













    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    1














    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');
    })
    }

    ....
    }





    share|improve this answer




























      1














      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');
      })
      }

      ....
      }





      share|improve this answer


























        1












        1








        1






        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');
        })
        }

        ....
        }





        share|improve this answer














        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');
        })
        }

        ....
        }






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 23 '18 at 6:08

























        answered Nov 23 '18 at 5:49









        Bharath Kumar S

        582317




        582317

























            1














            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






            share|improve this answer





















            • 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


















            1














            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






            share|improve this answer





















            • 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
















            1












            1








            1






            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






            share|improve this answer












            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







            share|improve this answer












            share|improve this answer



            share|improve this answer










            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




















            • 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




















            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Berounka

            Sphinx de Gizeh

            Different font size/position of beamer's navigation symbols template's content depending on regular/plain...