Deleting test database in Vapor 3












5















I want to write some integration tests for Vapor 3 server and I need to have clean Postgre database each time I run my tests. How can I achieve this? It seems migrations isn't the right way to go as they've been running once if database doesn't exist yet.










share|improve this question

























  • Have you tried using raw SQL queries ? Also, drop table is part of the SQL package

    – nathan
    Nov 20 '18 at 14:33











  • @nathan and what is the proper place to run this query in vapor3 project?

    – m8labs
    Nov 20 '18 at 16:42






  • 1





    Using XCTestCase ? stackoverflow.com/questions/29822457/…

    – nathan
    Nov 20 '18 at 16:50
















5















I want to write some integration tests for Vapor 3 server and I need to have clean Postgre database each time I run my tests. How can I achieve this? It seems migrations isn't the right way to go as they've been running once if database doesn't exist yet.










share|improve this question

























  • Have you tried using raw SQL queries ? Also, drop table is part of the SQL package

    – nathan
    Nov 20 '18 at 14:33











  • @nathan and what is the proper place to run this query in vapor3 project?

    – m8labs
    Nov 20 '18 at 16:42






  • 1





    Using XCTestCase ? stackoverflow.com/questions/29822457/…

    – nathan
    Nov 20 '18 at 16:50














5












5








5








I want to write some integration tests for Vapor 3 server and I need to have clean Postgre database each time I run my tests. How can I achieve this? It seems migrations isn't the right way to go as they've been running once if database doesn't exist yet.










share|improve this question
















I want to write some integration tests for Vapor 3 server and I need to have clean Postgre database each time I run my tests. How can I achieve this? It seems migrations isn't the right way to go as they've been running once if database doesn't exist yet.







swift vapor vapor3






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 19 '18 at 22:57







m8labs

















asked Nov 19 '18 at 20:12









m8labsm8labs

2,66612126




2,66612126













  • Have you tried using raw SQL queries ? Also, drop table is part of the SQL package

    – nathan
    Nov 20 '18 at 14:33











  • @nathan and what is the proper place to run this query in vapor3 project?

    – m8labs
    Nov 20 '18 at 16:42






  • 1





    Using XCTestCase ? stackoverflow.com/questions/29822457/…

    – nathan
    Nov 20 '18 at 16:50



















  • Have you tried using raw SQL queries ? Also, drop table is part of the SQL package

    – nathan
    Nov 20 '18 at 14:33











  • @nathan and what is the proper place to run this query in vapor3 project?

    – m8labs
    Nov 20 '18 at 16:42






  • 1





    Using XCTestCase ? stackoverflow.com/questions/29822457/…

    – nathan
    Nov 20 '18 at 16:50

















Have you tried using raw SQL queries ? Also, drop table is part of the SQL package

– nathan
Nov 20 '18 at 14:33





Have you tried using raw SQL queries ? Also, drop table is part of the SQL package

– nathan
Nov 20 '18 at 14:33













@nathan and what is the proper place to run this query in vapor3 project?

– m8labs
Nov 20 '18 at 16:42





@nathan and what is the proper place to run this query in vapor3 project?

– m8labs
Nov 20 '18 at 16:42




1




1





Using XCTestCase ? stackoverflow.com/questions/29822457/…

– nathan
Nov 20 '18 at 16:50





Using XCTestCase ? stackoverflow.com/questions/29822457/…

– nathan
Nov 20 '18 at 16:50












2 Answers
2






active

oldest

votes


















5














Have a look at https://github.com/raywenderlich/vapor-til/tree/master/Tests



This requires a DB to be running before you run the tests, but it reverts all migrations at the start of each test run, which gives you a clean DB each time. (Specifically here)



There's also a docker-compose.yml in the root directory for spinning up a completely isolated test environment on Linux






share|improve this answer
























  • I've inspected sources and have some concerns - isn't it extremely wasteful to run different instance of the Application (2 times in a row) before each test method? Why don't they use "override class func setUp()" instead?...

    – m8labs
    Nov 22 '18 at 15:11











  • Running the commands (revert and prepare) require an application to boot up. When you provide the application a command it will exit upon completion, so if you do it the way above you don't have much choice for integration tests

    – 0xTim
    Nov 23 '18 at 13:01



















1














I've found a solution that is less resource-intensive, then reverting all migrations every time.



RSpec has a configuration (use_transactional_fixtures) that allows wrapping every test in an SQL transaction. When testing is over it will rollback the transaction and in consequence revert all the changes that happened during testing. Relevant documentation is here.



We can implement a similar solution in Vapor. My example test looks like this.



final class VaporTests: XCTestCase {

var app: Application!

override func setUp() {
super.setUp()

app = try! Application.buildForTesting()
let conn = try! app.requestPooledConnection(to: .psql).wait()
try! conn.simpleQuery("BEGIN TRANSACTION").wait()
try! app.releasePooledConnection(conn, to: .psql)
}

override func tearDown() {
let conn = try! app.requestPooledConnection(to: .psql).wait()
try! conn.simpleQuery("ROLLBACK").wait()
try! app.releasePooledConnection(conn, to: .psql)

super.tearDown()
}

func testExample() throws {
let request = HTTPRequest(method: .GET, url: "my/endpoint/example")
let wrapper = Request(http: request, using: app)

let response = try ExampleController().example(wrapper).wait()

XCTAssertEqual(response, .ok)
}
}


To make sure that I don't encounter issues with concurrency I'm limiting database pool to 1 connection in the test application.



func configure(_ config: inout Config, _ env: inout Environment, _ services: inout Services) throws {
// ... other configurations

let poolConfig = DatabaseConnectionPoolConfig(maxConnections: 1)
services.register(poolConfig)
}


Many thanks to Jakub Jatczak for helping me to find out how this happens in Rails.






share|improve this answer























    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%2f53381955%2fdeleting-test-database-in-vapor-3%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









    5














    Have a look at https://github.com/raywenderlich/vapor-til/tree/master/Tests



    This requires a DB to be running before you run the tests, but it reverts all migrations at the start of each test run, which gives you a clean DB each time. (Specifically here)



    There's also a docker-compose.yml in the root directory for spinning up a completely isolated test environment on Linux






    share|improve this answer
























    • I've inspected sources and have some concerns - isn't it extremely wasteful to run different instance of the Application (2 times in a row) before each test method? Why don't they use "override class func setUp()" instead?...

      – m8labs
      Nov 22 '18 at 15:11











    • Running the commands (revert and prepare) require an application to boot up. When you provide the application a command it will exit upon completion, so if you do it the way above you don't have much choice for integration tests

      – 0xTim
      Nov 23 '18 at 13:01
















    5














    Have a look at https://github.com/raywenderlich/vapor-til/tree/master/Tests



    This requires a DB to be running before you run the tests, but it reverts all migrations at the start of each test run, which gives you a clean DB each time. (Specifically here)



    There's also a docker-compose.yml in the root directory for spinning up a completely isolated test environment on Linux






    share|improve this answer
























    • I've inspected sources and have some concerns - isn't it extremely wasteful to run different instance of the Application (2 times in a row) before each test method? Why don't they use "override class func setUp()" instead?...

      – m8labs
      Nov 22 '18 at 15:11











    • Running the commands (revert and prepare) require an application to boot up. When you provide the application a command it will exit upon completion, so if you do it the way above you don't have much choice for integration tests

      – 0xTim
      Nov 23 '18 at 13:01














    5












    5








    5







    Have a look at https://github.com/raywenderlich/vapor-til/tree/master/Tests



    This requires a DB to be running before you run the tests, but it reverts all migrations at the start of each test run, which gives you a clean DB each time. (Specifically here)



    There's also a docker-compose.yml in the root directory for spinning up a completely isolated test environment on Linux






    share|improve this answer













    Have a look at https://github.com/raywenderlich/vapor-til/tree/master/Tests



    This requires a DB to be running before you run the tests, but it reverts all migrations at the start of each test run, which gives you a clean DB each time. (Specifically here)



    There's also a docker-compose.yml in the root directory for spinning up a completely isolated test environment on Linux







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Nov 20 '18 at 20:02









    0xTim0xTim

    961412




    961412













    • I've inspected sources and have some concerns - isn't it extremely wasteful to run different instance of the Application (2 times in a row) before each test method? Why don't they use "override class func setUp()" instead?...

      – m8labs
      Nov 22 '18 at 15:11











    • Running the commands (revert and prepare) require an application to boot up. When you provide the application a command it will exit upon completion, so if you do it the way above you don't have much choice for integration tests

      – 0xTim
      Nov 23 '18 at 13:01



















    • I've inspected sources and have some concerns - isn't it extremely wasteful to run different instance of the Application (2 times in a row) before each test method? Why don't they use "override class func setUp()" instead?...

      – m8labs
      Nov 22 '18 at 15:11











    • Running the commands (revert and prepare) require an application to boot up. When you provide the application a command it will exit upon completion, so if you do it the way above you don't have much choice for integration tests

      – 0xTim
      Nov 23 '18 at 13:01

















    I've inspected sources and have some concerns - isn't it extremely wasteful to run different instance of the Application (2 times in a row) before each test method? Why don't they use "override class func setUp()" instead?...

    – m8labs
    Nov 22 '18 at 15:11





    I've inspected sources and have some concerns - isn't it extremely wasteful to run different instance of the Application (2 times in a row) before each test method? Why don't they use "override class func setUp()" instead?...

    – m8labs
    Nov 22 '18 at 15:11













    Running the commands (revert and prepare) require an application to boot up. When you provide the application a command it will exit upon completion, so if you do it the way above you don't have much choice for integration tests

    – 0xTim
    Nov 23 '18 at 13:01





    Running the commands (revert and prepare) require an application to boot up. When you provide the application a command it will exit upon completion, so if you do it the way above you don't have much choice for integration tests

    – 0xTim
    Nov 23 '18 at 13:01













    1














    I've found a solution that is less resource-intensive, then reverting all migrations every time.



    RSpec has a configuration (use_transactional_fixtures) that allows wrapping every test in an SQL transaction. When testing is over it will rollback the transaction and in consequence revert all the changes that happened during testing. Relevant documentation is here.



    We can implement a similar solution in Vapor. My example test looks like this.



    final class VaporTests: XCTestCase {

    var app: Application!

    override func setUp() {
    super.setUp()

    app = try! Application.buildForTesting()
    let conn = try! app.requestPooledConnection(to: .psql).wait()
    try! conn.simpleQuery("BEGIN TRANSACTION").wait()
    try! app.releasePooledConnection(conn, to: .psql)
    }

    override func tearDown() {
    let conn = try! app.requestPooledConnection(to: .psql).wait()
    try! conn.simpleQuery("ROLLBACK").wait()
    try! app.releasePooledConnection(conn, to: .psql)

    super.tearDown()
    }

    func testExample() throws {
    let request = HTTPRequest(method: .GET, url: "my/endpoint/example")
    let wrapper = Request(http: request, using: app)

    let response = try ExampleController().example(wrapper).wait()

    XCTAssertEqual(response, .ok)
    }
    }


    To make sure that I don't encounter issues with concurrency I'm limiting database pool to 1 connection in the test application.



    func configure(_ config: inout Config, _ env: inout Environment, _ services: inout Services) throws {
    // ... other configurations

    let poolConfig = DatabaseConnectionPoolConfig(maxConnections: 1)
    services.register(poolConfig)
    }


    Many thanks to Jakub Jatczak for helping me to find out how this happens in Rails.






    share|improve this answer




























      1














      I've found a solution that is less resource-intensive, then reverting all migrations every time.



      RSpec has a configuration (use_transactional_fixtures) that allows wrapping every test in an SQL transaction. When testing is over it will rollback the transaction and in consequence revert all the changes that happened during testing. Relevant documentation is here.



      We can implement a similar solution in Vapor. My example test looks like this.



      final class VaporTests: XCTestCase {

      var app: Application!

      override func setUp() {
      super.setUp()

      app = try! Application.buildForTesting()
      let conn = try! app.requestPooledConnection(to: .psql).wait()
      try! conn.simpleQuery("BEGIN TRANSACTION").wait()
      try! app.releasePooledConnection(conn, to: .psql)
      }

      override func tearDown() {
      let conn = try! app.requestPooledConnection(to: .psql).wait()
      try! conn.simpleQuery("ROLLBACK").wait()
      try! app.releasePooledConnection(conn, to: .psql)

      super.tearDown()
      }

      func testExample() throws {
      let request = HTTPRequest(method: .GET, url: "my/endpoint/example")
      let wrapper = Request(http: request, using: app)

      let response = try ExampleController().example(wrapper).wait()

      XCTAssertEqual(response, .ok)
      }
      }


      To make sure that I don't encounter issues with concurrency I'm limiting database pool to 1 connection in the test application.



      func configure(_ config: inout Config, _ env: inout Environment, _ services: inout Services) throws {
      // ... other configurations

      let poolConfig = DatabaseConnectionPoolConfig(maxConnections: 1)
      services.register(poolConfig)
      }


      Many thanks to Jakub Jatczak for helping me to find out how this happens in Rails.






      share|improve this answer


























        1












        1








        1







        I've found a solution that is less resource-intensive, then reverting all migrations every time.



        RSpec has a configuration (use_transactional_fixtures) that allows wrapping every test in an SQL transaction. When testing is over it will rollback the transaction and in consequence revert all the changes that happened during testing. Relevant documentation is here.



        We can implement a similar solution in Vapor. My example test looks like this.



        final class VaporTests: XCTestCase {

        var app: Application!

        override func setUp() {
        super.setUp()

        app = try! Application.buildForTesting()
        let conn = try! app.requestPooledConnection(to: .psql).wait()
        try! conn.simpleQuery("BEGIN TRANSACTION").wait()
        try! app.releasePooledConnection(conn, to: .psql)
        }

        override func tearDown() {
        let conn = try! app.requestPooledConnection(to: .psql).wait()
        try! conn.simpleQuery("ROLLBACK").wait()
        try! app.releasePooledConnection(conn, to: .psql)

        super.tearDown()
        }

        func testExample() throws {
        let request = HTTPRequest(method: .GET, url: "my/endpoint/example")
        let wrapper = Request(http: request, using: app)

        let response = try ExampleController().example(wrapper).wait()

        XCTAssertEqual(response, .ok)
        }
        }


        To make sure that I don't encounter issues with concurrency I'm limiting database pool to 1 connection in the test application.



        func configure(_ config: inout Config, _ env: inout Environment, _ services: inout Services) throws {
        // ... other configurations

        let poolConfig = DatabaseConnectionPoolConfig(maxConnections: 1)
        services.register(poolConfig)
        }


        Many thanks to Jakub Jatczak for helping me to find out how this happens in Rails.






        share|improve this answer













        I've found a solution that is less resource-intensive, then reverting all migrations every time.



        RSpec has a configuration (use_transactional_fixtures) that allows wrapping every test in an SQL transaction. When testing is over it will rollback the transaction and in consequence revert all the changes that happened during testing. Relevant documentation is here.



        We can implement a similar solution in Vapor. My example test looks like this.



        final class VaporTests: XCTestCase {

        var app: Application!

        override func setUp() {
        super.setUp()

        app = try! Application.buildForTesting()
        let conn = try! app.requestPooledConnection(to: .psql).wait()
        try! conn.simpleQuery("BEGIN TRANSACTION").wait()
        try! app.releasePooledConnection(conn, to: .psql)
        }

        override func tearDown() {
        let conn = try! app.requestPooledConnection(to: .psql).wait()
        try! conn.simpleQuery("ROLLBACK").wait()
        try! app.releasePooledConnection(conn, to: .psql)

        super.tearDown()
        }

        func testExample() throws {
        let request = HTTPRequest(method: .GET, url: "my/endpoint/example")
        let wrapper = Request(http: request, using: app)

        let response = try ExampleController().example(wrapper).wait()

        XCTAssertEqual(response, .ok)
        }
        }


        To make sure that I don't encounter issues with concurrency I'm limiting database pool to 1 connection in the test application.



        func configure(_ config: inout Config, _ env: inout Environment, _ services: inout Services) throws {
        // ... other configurations

        let poolConfig = DatabaseConnectionPoolConfig(maxConnections: 1)
        services.register(poolConfig)
        }


        Many thanks to Jakub Jatczak for helping me to find out how this happens in Rails.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 4 at 15:52









        Tomasz BąkTomasz Bąk

        4,51422742




        4,51422742






























            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%2f53381955%2fdeleting-test-database-in-vapor-3%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

            鏡平學校

            ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

            Guess what letter conforming each word