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