Deleting test database in Vapor 3
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
add a comment |
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
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
add a comment |
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
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
swift vapor vapor3
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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
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
add a comment |
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.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%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
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
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
add a comment |
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
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
add a comment |
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
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
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Jan 4 at 15:52
Tomasz BąkTomasz Bąk
4,51422742
4,51422742
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53381955%2fdeleting-test-database-in-vapor-3%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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