VS Unit test on database procedures inMemory that can be integrated with continuous delivery pipeline









up vote
2
down vote

favorite












So Im trying to figure out a way to properly unit test database procedures in visual studio so I can integrate it into our deployment pipeline.



what I am doing right now is create a database project and link it to our database. Then generate unit test with visual studio on the procedures. The problem is that unit testing the procedures this way will make changes to data in the actual database (which I don't want). Another problem is when someone make change to the database without updating that database project



I can either:



  1. do a rollback after every unit test (but there are some procedures that contain commit, so even if I rollback in c#, some part will still get committed)


  2. create a testing database (not an option in my situation)


  3. create a in-memory database (I prefer this option. I checked out SQLite. However it doesn't seem to support procedures)


Any advises or suggestions are appreciated










share|improve this question



























    up vote
    2
    down vote

    favorite












    So Im trying to figure out a way to properly unit test database procedures in visual studio so I can integrate it into our deployment pipeline.



    what I am doing right now is create a database project and link it to our database. Then generate unit test with visual studio on the procedures. The problem is that unit testing the procedures this way will make changes to data in the actual database (which I don't want). Another problem is when someone make change to the database without updating that database project



    I can either:



    1. do a rollback after every unit test (but there are some procedures that contain commit, so even if I rollback in c#, some part will still get committed)


    2. create a testing database (not an option in my situation)


    3. create a in-memory database (I prefer this option. I checked out SQLite. However it doesn't seem to support procedures)


    Any advises or suggestions are appreciated










    share|improve this question

























      up vote
      2
      down vote

      favorite









      up vote
      2
      down vote

      favorite











      So Im trying to figure out a way to properly unit test database procedures in visual studio so I can integrate it into our deployment pipeline.



      what I am doing right now is create a database project and link it to our database. Then generate unit test with visual studio on the procedures. The problem is that unit testing the procedures this way will make changes to data in the actual database (which I don't want). Another problem is when someone make change to the database without updating that database project



      I can either:



      1. do a rollback after every unit test (but there are some procedures that contain commit, so even if I rollback in c#, some part will still get committed)


      2. create a testing database (not an option in my situation)


      3. create a in-memory database (I prefer this option. I checked out SQLite. However it doesn't seem to support procedures)


      Any advises or suggestions are appreciated










      share|improve this question















      So Im trying to figure out a way to properly unit test database procedures in visual studio so I can integrate it into our deployment pipeline.



      what I am doing right now is create a database project and link it to our database. Then generate unit test with visual studio on the procedures. The problem is that unit testing the procedures this way will make changes to data in the actual database (which I don't want). Another problem is when someone make change to the database without updating that database project



      I can either:



      1. do a rollback after every unit test (but there are some procedures that contain commit, so even if I rollback in c#, some part will still get committed)


      2. create a testing database (not an option in my situation)


      3. create a in-memory database (I prefer this option. I checked out SQLite. However it doesn't seem to support procedures)


      Any advises or suggestions are appreciated







      sql sql-server unit-testing tsql stored-procedures






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 12 at 9:56









      Rahul Neekhra

      602627




      602627










      asked Nov 11 at 16:25









      user308553

      5511823




      5511823






















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          2
          down vote



          accepted











          1. create a in-memory database (I prefer this option. I checked out SQLite. However it doesn't seem to support procedures)



          SQL Server do not support in-memory option




          1. create a testing database (not an option in my situation)



          This is usually a best option for tests against an actual database.

          Tests should be executed in isolation of each other to produce consistent and trusted result.

          Nobody will break your testing database, because you will run a script to create it and fill with the required data before tests.




          1. do a rollback after every unit test (but there are some procedures that contain commit, so even if I rollback in c#, some part will still
            get committed)



          Try to use TransactionScope Class which should rollback internal transactions committed during test.

          But if you are using some database which used by others, your tests can possibly fail because somebody made changes.






          share|improve this answer




















          • For the rollback option. Let's say I do everything in a Transaction scope. Running a script to prep the database, run my procedure, check if data is correct, then do a rollback. This is a dev database use by other teams. What sort of problem would I have to watch out for if I use this rollback option?
            – user308553
            Nov 20 at 22:26











          • Don't use dev database, create own for tests.
            – Fabio
            Nov 21 at 4:26










          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',
          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%2f53250748%2fvs-unit-test-on-database-procedures-inmemory-that-can-be-integrated-with-continu%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








          up vote
          2
          down vote



          accepted











          1. create a in-memory database (I prefer this option. I checked out SQLite. However it doesn't seem to support procedures)



          SQL Server do not support in-memory option




          1. create a testing database (not an option in my situation)



          This is usually a best option for tests against an actual database.

          Tests should be executed in isolation of each other to produce consistent and trusted result.

          Nobody will break your testing database, because you will run a script to create it and fill with the required data before tests.




          1. do a rollback after every unit test (but there are some procedures that contain commit, so even if I rollback in c#, some part will still
            get committed)



          Try to use TransactionScope Class which should rollback internal transactions committed during test.

          But if you are using some database which used by others, your tests can possibly fail because somebody made changes.






          share|improve this answer




















          • For the rollback option. Let's say I do everything in a Transaction scope. Running a script to prep the database, run my procedure, check if data is correct, then do a rollback. This is a dev database use by other teams. What sort of problem would I have to watch out for if I use this rollback option?
            – user308553
            Nov 20 at 22:26











          • Don't use dev database, create own for tests.
            – Fabio
            Nov 21 at 4:26














          up vote
          2
          down vote



          accepted











          1. create a in-memory database (I prefer this option. I checked out SQLite. However it doesn't seem to support procedures)



          SQL Server do not support in-memory option




          1. create a testing database (not an option in my situation)



          This is usually a best option for tests against an actual database.

          Tests should be executed in isolation of each other to produce consistent and trusted result.

          Nobody will break your testing database, because you will run a script to create it and fill with the required data before tests.




          1. do a rollback after every unit test (but there are some procedures that contain commit, so even if I rollback in c#, some part will still
            get committed)



          Try to use TransactionScope Class which should rollback internal transactions committed during test.

          But if you are using some database which used by others, your tests can possibly fail because somebody made changes.






          share|improve this answer




















          • For the rollback option. Let's say I do everything in a Transaction scope. Running a script to prep the database, run my procedure, check if data is correct, then do a rollback. This is a dev database use by other teams. What sort of problem would I have to watch out for if I use this rollback option?
            – user308553
            Nov 20 at 22:26











          • Don't use dev database, create own for tests.
            – Fabio
            Nov 21 at 4:26












          up vote
          2
          down vote



          accepted







          up vote
          2
          down vote



          accepted







          1. create a in-memory database (I prefer this option. I checked out SQLite. However it doesn't seem to support procedures)



          SQL Server do not support in-memory option




          1. create a testing database (not an option in my situation)



          This is usually a best option for tests against an actual database.

          Tests should be executed in isolation of each other to produce consistent and trusted result.

          Nobody will break your testing database, because you will run a script to create it and fill with the required data before tests.




          1. do a rollback after every unit test (but there are some procedures that contain commit, so even if I rollback in c#, some part will still
            get committed)



          Try to use TransactionScope Class which should rollback internal transactions committed during test.

          But if you are using some database which used by others, your tests can possibly fail because somebody made changes.






          share|improve this answer













          1. create a in-memory database (I prefer this option. I checked out SQLite. However it doesn't seem to support procedures)



          SQL Server do not support in-memory option




          1. create a testing database (not an option in my situation)



          This is usually a best option for tests against an actual database.

          Tests should be executed in isolation of each other to produce consistent and trusted result.

          Nobody will break your testing database, because you will run a script to create it and fill with the required data before tests.




          1. do a rollback after every unit test (but there are some procedures that contain commit, so even if I rollback in c#, some part will still
            get committed)



          Try to use TransactionScope Class which should rollback internal transactions committed during test.

          But if you are using some database which used by others, your tests can possibly fail because somebody made changes.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 12 at 3:59









          Fabio

          18.9k22044




          18.9k22044











          • For the rollback option. Let's say I do everything in a Transaction scope. Running a script to prep the database, run my procedure, check if data is correct, then do a rollback. This is a dev database use by other teams. What sort of problem would I have to watch out for if I use this rollback option?
            – user308553
            Nov 20 at 22:26











          • Don't use dev database, create own for tests.
            – Fabio
            Nov 21 at 4:26
















          • For the rollback option. Let's say I do everything in a Transaction scope. Running a script to prep the database, run my procedure, check if data is correct, then do a rollback. This is a dev database use by other teams. What sort of problem would I have to watch out for if I use this rollback option?
            – user308553
            Nov 20 at 22:26











          • Don't use dev database, create own for tests.
            – Fabio
            Nov 21 at 4:26















          For the rollback option. Let's say I do everything in a Transaction scope. Running a script to prep the database, run my procedure, check if data is correct, then do a rollback. This is a dev database use by other teams. What sort of problem would I have to watch out for if I use this rollback option?
          – user308553
          Nov 20 at 22:26





          For the rollback option. Let's say I do everything in a Transaction scope. Running a script to prep the database, run my procedure, check if data is correct, then do a rollback. This is a dev database use by other teams. What sort of problem would I have to watch out for if I use this rollback option?
          – user308553
          Nov 20 at 22:26













          Don't use dev database, create own for tests.
          – Fabio
          Nov 21 at 4:26




          Don't use dev database, create own for tests.
          – Fabio
          Nov 21 at 4:26

















          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%2f53250748%2fvs-unit-test-on-database-procedures-inmemory-that-can-be-integrated-with-continu%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

          Top Tejano songwriter Luis Silva dead of heart attack at 64

          ReactJS Fetched API data displays live - need Data displayed static

          政党