What is the best way to set up nested tests using mocha?












1















I am currently working on some tests, and I'd like to create some structure where I can logically nest my system tests.



Let's imagine I want to run the following tests :




  • user registers


    • with invalid data


      • it should fail



    • with valid data


      • it should succeed

      • user logs in


        • with invalid credentials


          • it should fail



        • with valid credentials


          • it should succeed

          • user lists stuff


            • no stuff is available


              • it should return empty list



            • stuff is available


              • it should return a list of stuff

              • user adds stuff to his cart


                • cart should show stuff
















... and so on.



Looking at this, this could become a nasty mess of nested 'describe' and 'it'.



What would be the best way to write these tests without having a huge file containing the nested describes ?



(One of ideas was to use dependency injection - awilix - to create scopes and then trickle down the stuff like tokens, product lists, ...)






node.js mocha







share|improve this question



























    1















    I am currently working on some tests, and I'd like to create some structure where I can logically nest my system tests.



    Let's imagine I want to run the following tests :




    • user registers


      • with invalid data


        • it should fail



      • with valid data


        • it should succeed

        • user logs in


          • with invalid credentials


            • it should fail



          • with valid credentials


            • it should succeed

            • user lists stuff


              • no stuff is available


                • it should return empty list



              • stuff is available


                • it should return a list of stuff

                • user adds stuff to his cart


                  • cart should show stuff
















    ... and so on.



    Looking at this, this could become a nasty mess of nested 'describe' and 'it'.



    What would be the best way to write these tests without having a huge file containing the nested describes ?



    (One of ideas was to use dependency injection - awilix - to create scopes and then trickle down the stuff like tokens, product lists, ...)






    node.js mocha







    share|improve this question

























      1












      1








      1








      I am currently working on some tests, and I'd like to create some structure where I can logically nest my system tests.



      Let's imagine I want to run the following tests :




      • user registers


        • with invalid data


          • it should fail



        • with valid data


          • it should succeed

          • user logs in


            • with invalid credentials


              • it should fail



            • with valid credentials


              • it should succeed

              • user lists stuff


                • no stuff is available


                  • it should return empty list



                • stuff is available


                  • it should return a list of stuff

                  • user adds stuff to his cart


                    • cart should show stuff
















      ... and so on.



      Looking at this, this could become a nasty mess of nested 'describe' and 'it'.



      What would be the best way to write these tests without having a huge file containing the nested describes ?



      (One of ideas was to use dependency injection - awilix - to create scopes and then trickle down the stuff like tokens, product lists, ...)






      node.js mocha







      share|improve this question














      I am currently working on some tests, and I'd like to create some structure where I can logically nest my system tests.



      Let's imagine I want to run the following tests :




      • user registers


        • with invalid data


          • it should fail



        • with valid data


          • it should succeed

          • user logs in


            • with invalid credentials


              • it should fail



            • with valid credentials


              • it should succeed

              • user lists stuff


                • no stuff is available


                  • it should return empty list



                • stuff is available


                  • it should return a list of stuff

                  • user adds stuff to his cart


                    • cart should show stuff
















      ... and so on.



      Looking at this, this could become a nasty mess of nested 'describe' and 'it'.



      What would be the best way to write these tests without having a huge file containing the nested describes ?



      (One of ideas was to use dependency injection - awilix - to create scopes and then trickle down the stuff like tokens, product lists, ...)






      node.js mocha




      node.js mocha






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 14 '18 at 23:16









      Simon GueroutSimon Guerout

      351213




      351213
























          1 Answer
          1






          active

          oldest

          votes


















          0














          I don't think there is some best way to do, what certainly matters is the readability and maintainability of your tests.



          My approach is rather subjective but I would keep the tests as flattened as possible, by using hooks if needed.



          For instance, the register and login tests would be rewritten as the following:




          • Register user


            • it should succeed (test case#1)

            • ...

            • it should succeed (test case#n)

            • it should fail (test case#1)

            • ...

            • it should fail (test case#n)



          • Login with registered user


            • Before Each hook - User should be registered

            • it should succeed (test case#1)

            • ...

            • it should succeed (test case#n)

            • it should fail (test case#1)

            • ...

            • it should fail (test case#n)



          • ...






          share|improve this answer
























          • Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.

            – Simon Guerout
            Nov 15 '18 at 0:15











          • @Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.

            – MuratK
            Nov 15 '18 at 8:00













          • You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!

            – Simon Guerout
            Nov 15 '18 at 21:13













          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%2f53310195%2fwhat-is-the-best-way-to-set-up-nested-tests-using-mocha%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          I don't think there is some best way to do, what certainly matters is the readability and maintainability of your tests.



          My approach is rather subjective but I would keep the tests as flattened as possible, by using hooks if needed.



          For instance, the register and login tests would be rewritten as the following:




          • Register user


            • it should succeed (test case#1)

            • ...

            • it should succeed (test case#n)

            • it should fail (test case#1)

            • ...

            • it should fail (test case#n)



          • Login with registered user


            • Before Each hook - User should be registered

            • it should succeed (test case#1)

            • ...

            • it should succeed (test case#n)

            • it should fail (test case#1)

            • ...

            • it should fail (test case#n)



          • ...






          share|improve this answer
























          • Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.

            – Simon Guerout
            Nov 15 '18 at 0:15











          • @Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.

            – MuratK
            Nov 15 '18 at 8:00













          • You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!

            – Simon Guerout
            Nov 15 '18 at 21:13


















          0














          I don't think there is some best way to do, what certainly matters is the readability and maintainability of your tests.



          My approach is rather subjective but I would keep the tests as flattened as possible, by using hooks if needed.



          For instance, the register and login tests would be rewritten as the following:




          • Register user


            • it should succeed (test case#1)

            • ...

            • it should succeed (test case#n)

            • it should fail (test case#1)

            • ...

            • it should fail (test case#n)



          • Login with registered user


            • Before Each hook - User should be registered

            • it should succeed (test case#1)

            • ...

            • it should succeed (test case#n)

            • it should fail (test case#1)

            • ...

            • it should fail (test case#n)



          • ...






          share|improve this answer
























          • Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.

            – Simon Guerout
            Nov 15 '18 at 0:15











          • @Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.

            – MuratK
            Nov 15 '18 at 8:00













          • You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!

            – Simon Guerout
            Nov 15 '18 at 21:13
















          0












          0








          0







          I don't think there is some best way to do, what certainly matters is the readability and maintainability of your tests.



          My approach is rather subjective but I would keep the tests as flattened as possible, by using hooks if needed.



          For instance, the register and login tests would be rewritten as the following:




          • Register user


            • it should succeed (test case#1)

            • ...

            • it should succeed (test case#n)

            • it should fail (test case#1)

            • ...

            • it should fail (test case#n)



          • Login with registered user


            • Before Each hook - User should be registered

            • it should succeed (test case#1)

            • ...

            • it should succeed (test case#n)

            • it should fail (test case#1)

            • ...

            • it should fail (test case#n)



          • ...






          share|improve this answer













          I don't think there is some best way to do, what certainly matters is the readability and maintainability of your tests.



          My approach is rather subjective but I would keep the tests as flattened as possible, by using hooks if needed.



          For instance, the register and login tests would be rewritten as the following:




          • Register user


            • it should succeed (test case#1)

            • ...

            • it should succeed (test case#n)

            • it should fail (test case#1)

            • ...

            • it should fail (test case#n)



          • Login with registered user


            • Before Each hook - User should be registered

            • it should succeed (test case#1)

            • ...

            • it should succeed (test case#n)

            • it should fail (test case#1)

            • ...

            • it should fail (test case#n)



          • ...







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 15 '18 at 0:02









          MuratKMuratK

          1655




          1655













          • Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.

            – Simon Guerout
            Nov 15 '18 at 0:15











          • @Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.

            – MuratK
            Nov 15 '18 at 8:00













          • You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!

            – Simon Guerout
            Nov 15 '18 at 21:13





















          • Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.

            – Simon Guerout
            Nov 15 '18 at 0:15











          • @Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.

            – MuratK
            Nov 15 '18 at 8:00













          • You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!

            – Simon Guerout
            Nov 15 '18 at 21:13



















          Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.

          – Simon Guerout
          Nov 15 '18 at 0:15





          Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.

          – Simon Guerout
          Nov 15 '18 at 0:15













          @Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.

          – MuratK
          Nov 15 '18 at 8:00







          @Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.

          – MuratK
          Nov 15 '18 at 8:00















          You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!

          – Simon Guerout
          Nov 15 '18 at 21:13







          You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!

          – Simon Guerout
          Nov 15 '18 at 21:13






















          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.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53310195%2fwhat-is-the-best-way-to-set-up-nested-tests-using-mocha%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

          Bressuire

          Image
          Subprefecture and commune in Nouvelle-Aquitaine, France Bressuire Subprefecture and commune Chateau de Bressuire and the Eglise Notre-Dame Coat of arms Location of Bressuire Bressuire Show map of France Bressuire Show map of Nouvelle-Aquitaine Coordinates: 46°50′27″N 0°29′14″W  /  46.8408°N 0.4872°W  / 46.8408; -0.4872 Coordinates: 46°50′27″N 0°29′14″W  /  46.8408°N 0.4872°W  / 46.8408; -0.4872 Country France Region Nouvelle-Aquitaine Department Deux-Sèvres Arrondissement Bressuire Canton Bressuire Government  • Mayor .mw-parser-output .nobold{font-weight:normal} (2014–20) Jean Michel Bernier Area 1 180.59 km 2 (69.73 sq mi) Population (2014) 2 19,300  • Density 110/km 2 (280/sq mi) Time zone UTC+01:00 (CET)  • Summer (DST) UTC+02:00 (CEST) INSEE/Postal code 79049 /79300 Elevation 98–236 m (322–774 ft) (avg. 173 m or 568 ft) 1 French Land Register data, which exclude...
          Read more

          Vorschmack

          Image
          Vorschmack Ukrainian Jewish-style vorschmack served on rye bread Course Hors d'oeuvre Region or state Eastern Europe Associated national cuisine Ashkenazi Jewish, Finnish, German, Ukrainian, Polish, Russian Main ingredients Ground meat and/or fish Cookbook: Vorschmack   Media: Vorschmack Vorschmack or forshmak (Yiddish: פֿאָרשמאַק ‎, from archaic German Vorschmack , "foretaste" [1] or "appetizer" [2] ) is an originally East European dish made of salty minced fish or meat. Different variants of this dish are especially common in Ashkenazi Jewish and Finnish cuisine. Some varieties are also known in Russian and Polish cuisine. Contents 1 In Jewish cuisine 2 In Russian cuisine 3 In Polish cuisine 4 In Finnish cuisine 5 See also 6 References In Jewish cuisine According to Gil Marks, the German name points to the possible Germanic origin of this dish. [1] William Pokhlyobkin descr...
          Read more

          Quarantine

          Image
          For other uses, see Quarantine (disambiguation). Signal flag "Lima" called the "Yellow Jack" which when flown in harbor means ship is under quarantine. A simple yellow flag (also called the "Yellow Jack") had historically been used to signal quarantine (it stands for Q among signal flags), but now indicates the opposite, as a signal of a ship free of disease that requests boarding and inspection. A quarantine is used to separate and restrict the movement of people; it is 'a restraint upon the activities or communication of persons or the transport of goods designed to prevent the spread of disease or pests', for a certain period of time. [1] This is often used in connection to disease and illness, such as those who may possibly have been exposed to a communicable disease. [2] The term is often erroneously used to mean medical isolation, which is "to separate ill persons who have a communicable disease from those who are healthy...
          Read more