Support integration tests #43
Comments
|
Is it possible to specify different postgres schemas to create and use when testing rather than the default |
|
@bickelj not sure what you mean exactly. it's possible to mock databases, which I think would be useful in unit tests, but I think integration tests would be more robust using the true pg database + migrations. (Is any of that useful / responsive to your question?) |
|
@slifty I see that some of the above resources mention creating separate databases for test isolation, which makes sense, like |
|
@slifty Perhaps one advantage of separate schemas for isolation would be re-use of the connection pool by all tests. Then again, that's a kind of test non-isolation, so it could be a drawback. It would probably be cleanest to have a separate single connection to a separate single database for each test. |
|
Ahhhhh got it -- that would be truly excellent. I'll check out. At the very least using a separate schema within a database is not having to give "create db" permissions to the test user. ty for raising it! |
Integration tests are slower than unit tests because they rely on a database connection, so we want the ability to run them separately depending on our environment. Jest allows us to define different config files. By creating a `base` config we can define all of the common settings between unit and integration tests, and then customize for each type in the respective extended configs. In addition to configuration this begins to define define some hooks that make it possible to run tests in parallel. We can't actually use these hooks properly until an upstream bug is fixed in our migration package: ThomWright/postgres-migrations#92 Issue #43 Support integration tests
Integration tests are slower than unit tests because they rely on a database connection, so we want the ability to run them separately depending on our environment. Jest allows us to define different config files. By creating a `base` config we can define all of the common settings between unit and integration tests, and then customize for each type in the respective extended configs. In addition to configuration this begins to define define some hooks so that we can eventually run these tests in parallel. Unfortunately there is a bug in the migration library we're using which prevents that kind of parallel migration within a single database / across multiple schemas. We have an open PR with a patch for that bug[1]. [1] ThomWright/postgres-migrations#93 Issue #43 Support integration tests
Integration tests are slower than unit tests because they rely on a database connection, so we want the ability to run them separately depending on our environment. Jest allows us to define different config files. By creating a `base` config we can define all of the common settings between unit and integration tests, and then customize for each type in the respective extended configs. In addition to configuration this begins to define define some hooks so that we can eventually run these tests in parallel. Unfortunately there is a bug in the migration library we're using which prevents that kind of parallel migration within a single database / across multiple schemas. We have an open PR with a patch for that bug[1]. [1] ThomWright/postgres-migrations#93 Issue #43 Support integration tests
Integration tests are slower than unit tests because they rely on a database connection, so we want the ability to run them separately depending on our environment. Jest allows us to define different config files. By creating a `base` config we can define all of the common settings between unit and integration tests, and then customize for each type in the respective extended configs. In addition to configuration this begins to define define some hooks so that we can eventually run these tests in parallel. Unfortunately there is a bug in the migration library we're using which prevents that kind of parallel migration within a single database / across multiple schemas. We have an open PR with a patch for that bug[1]. [1] ThomWright/postgres-migrations#93 Issue #43 Support integration tests
Integration tests are slower than unit tests because they rely on a database connection, so we want the ability to run them separately depending on our environment. Jest allows us to define different config files. By creating a `base` config we can define all of the common settings between unit and integration tests, and then customize for each type in the respective extended configs. In addition to configuration this begins to define define some hooks so that we can eventually run these tests in parallel. Unfortunately there is a bug in the migration library we're using which prevents that kind of parallel migration within a single database / across multiple schemas. We have an open PR with a patch for that bug[1]. I took out the explicit running of migrations because our integration tests should now cover that (as they do run migrations). [1] ThomWright/postgres-migrations#93 Issue #43 Support integration tests
Integration tests are slower than unit tests because they rely on a database connection, so we want the ability to run them separately depending on our environment. Jest allows us to define different config files. By creating a `base` config we can define all of the common settings between unit and integration tests, and then customize for each type in the respective extended configs. In addition to configuration this begins to define define some hooks so that we can eventually run these tests in parallel. Unfortunately there is a bug in the migration library we're using which prevents that kind of parallel migration within a single database / across multiple schemas. We have an open PR with a patch for that bug[1]. I took out the explicit running of migrations because our integration tests should now cover that (as they do run migrations). [1] ThomWright/postgres-migrations#93 Issue #43 Support integration tests
|
I have been trying to get the tests to fail properly when there is a connection failure to the db. On main, I get a timeout failure followed by "there are asynchronous operations that weren't stopped in your tests." I have tried a couple of things but it looks like |
|
I have some |
|
Hmmm interesting -- this does sound pesky. I wonder if there's a way to (A) signal that beforeEach is async and (B) fail a test from within beforeEach if the db connection is not formed. I don't think we can avoid the timeout issue (though we could make it easier to configure timeout so that tests can configure a shorter timeout) meta side note -- what do you think about opening a new issue just for this specific problem (I think we technically have implemented this issue as written). |
|
I have peppered my local modified version of some code associated with PR #31 with logger.debug statements. I think you summarized it well as (A) having to do with |
|
Created #53 with some snippets. |
|
Thank you! I have one small patch I'm going to make to this issue (the bug you found notwithstanding) -- which is to have the harness functions called by the suite (apparently Jest stops test flow if there is a failure, and so |
Manually calling the DB setup / teardown within a test was verbose, but more importantly it meant teardown wouldn't happen if a test failed. That's no good! By using Jest's suite functionality we ensure that setup and teardown both run for each test regardless of test outcome. Issue #43 Support integration tests
Manually calling the DB setup / teardown within a test was verbose, but more importantly it meant teardown wouldn't happen if a test failed. That's no good! By using Jest's suite functionality we ensure that setup and teardown both run for each test regardless of test outcome. Issue #43 Support integration tests
Manually calling the DB setup / teardown within a test was verbose, but more importantly it meant teardown wouldn't happen if a test failed. That's no good! By using Jest's suite functionality we ensure that setup and teardown both run for each test regardless of test outcome. Issue #43 Support integration tests
Manually calling the DB setup / teardown within a test was verbose, but more importantly it meant teardown wouldn't happen if a test failed. That's no good! By using Jest's suite functionality we ensure that setup and teardown both run for each test regardless of test outcome. Issue #43 Support integration tests
Manually calling the DB setup / teardown within a test was verbose, but more importantly it meant teardown wouldn't happen if a test failed. That's no good! By using Jest's suite functionality we ensure that setup and teardown both run for each test regardless of test outcome. Issue #43 Support integration tests
We're about to need to run integration tests (I imagine many of our tests will rely on DB access in fact!)
This will mean three test commands:
npm run test:unit-- runs unit tests (no database)npm run test:integration-- runs untegration testsnpm run test-- runs both sets of testsPart of this issue will be figuring out the right way to do integration tests so that they're run in parallel but don't step on each other.
Potential resources I've found:
https://dev.to/walrusai/testing-database-interactions-with-jest-519n
https://jestjs.io/docs/setup-teardown
https://jestjs.io/docs/configuration#testmatch-arraystring
The text was updated successfully, but these errors were encountered: