S
SolidJS12mo ago
oneiro

Easiest way to spin up an e2e/integration-test setup with solid-start?

Hey folks, I am currently trying to figure out what would be a good way to build an integration and e2e-testing setup for solid-start. Essentially my integration tests should be able to connect to a database and only test server-side logic (for UI stuff I would simply use testing-library). E2E-tests should spin up a database as well as the solid-start application. Now here are the hurdles I have yet to overcome: 1. I would definitely like to use docker to spin up my database (we use docker-compose for our dev setup anyway). Ideally in conjunction with test containers. However our database connection is currently initalized via environment variables from an .env-file and with testcontainers I am unsure how I would ideally overwrite these after our database has been imported (this would be necessary, as testcontainers use a random port and I would also need to get the host) 2. What would be the best/easiest way to start my server. Ofcourse I could also run my solid-start app inside another container, but that feels a bit more exessive than I would like. Ideally I could start the server without the need for a container from my tests. So my general question would probably be: what do your integration/e2e-testsetups generally look like, when working with solid-start? Thanks in advance 🙂
1 Reply
oneiro
oneiro12mo ago
To elaborate a bit more on the database + environment part: in nodejs applications database connections typically seem just be instantiated in the root of a file and imported from there, e.g.:
// NOTE: connections details are pulled from psql env-variables
export const sql = postgres({});
// NOTE: connections details are pulled from psql env-variables
export const sql = postgres({});
The issue with this approach would be that in a typical integration test suit I would not be able to specify some of these environment variables before the module has been imported. This is because they might be dynamic - e.g. host and port from a testcontainer which is spun up inside the test suite itself. So I would have chicken-egg problem here. One solution for this problem I had in the past with a koa server, was to make the sql-variable a let binding and put the actual initialization into an initializer function. That way I kept the global import but was able to initialize the database at a point in time where all necessary information could be provided.
export let sql;
export const initDb() {
sql = postgres({})
}
export let sql;
export const initDb() {
sql = postgres({})
}
Now this probably also works with solid-start, but somehow this always felt hacky to me and I was wondering, if there is a better approach I am just not seeing.