I'd like to write some integration tests using www.eventstore.org to test that I am able to serialize some domain events and append them to a stream, and retrieve them and deserialize them, etc.
I've been trying to find how people generally do that and I read some Greg Young's answer (a bit outdated) about different approaches:
- I could generate different streams each time I execute my integration tests, but I prefer not to do so and not to pollute an event store with test data
- I could use an in-memory event store.
The second option seems ideal because I could simply run a clean event store, run my tests and stop the server at the end so that all the data is gone.
I've seen that it's possible to run the event store server with a parameter --mem-db not to persist anything in disk.
The question is: how to use an in-memory event store when running integration tests if, most likely, the OS where the tests are running has no event store binaries installed and therefore there's no real event store server to run in memory? I don't want my tests to fail just because there's no event store installed and up and running on the machine executing the tests.
I know some databases in the market have some nuGet package that contains the same DB engine used in production but as an in-memory DB so that no "real" server is needed on the machine to run the tests. All binaries are in a DLL available for the project.
I tried to find some answers on whether something like this is available for event store. I read some comments of people talking about some Embedded client API but the documentation I found is not very clear. Other comments mention something called MiniNode but, again, the threads assume too much and haven't yet found a clear description of what's that about or how could I use for my tests.
In summary, could anybody provide an example of an integration test (xUnit if possible) where the IEventStoreConnection is using an in-memory event store where there's no event store installed at all?
UPDATE 1: I tried to add the nuGet dependency EventStore.Client.Embedded to play with it just in case it was what I needed. But it does not have support for DotNetCore (standard 2.0) so I cannot tell. Then I read this ClientAPI.NetCore issue where somebody suggests to go with a different approach for testing, which is using Chocolatey to grab EventStore and then execute from the code the EventStore.ClusterNode (I would do that with the --mem-db flag). I'm not sure I like that, at least no more than using Docker for the same purpose. I am still wondering whether there's an alternative?
UPDATE 2 Since I am using gitlab, I run my integration tests with Event Store by spinning up an event store service (container) that will terminate as soon as the Continuous Integration step ends.
integration-tests:
image: my-images-repo/my-gitlab-runner-dotnet-core:latest
stage: integration-tests
services:
# add event store service
- eventstore/eventstore:release-4.1.1-hotfix1
variables:
# event store service params testing with standard ports
EVENTSTORE_INT_TCP_PORT: "1113"
EVENTSTORE_EXT_TCP_PORT: "1113"
EVENTSTORE_INT_HTTP_PORT: "2113"
EVENTSTORE_EXT_HTTP_PORT: "2113"
EVENTSTORE_EXT_HTTP_PREFIXES: "http://*:2113/"
script:
- dotnet restore --no-cache --force
- dotnet build --configuration Release
- dotnet vstest *IntegrationTests/bin/Release/**/*IntegrationTests.dll
This does yet answer my question but it's a solution for my needs.
UPDATE 3: (21 June 2019) There is still not support for the embedded client in netstandard 2.0 so I cannot use it to launch an in-memory node for testing purposes. There's however another option using docker described here
Also the EventStore C# API are now in the nuGet EventStore.Client (currently 5.0.1)