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
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.:
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.
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.