2
Crost
3y

I am working on an event driven system that uses a message bus and has a few services that talk to each other asynchronously via the bus.

I'm writing in memory integration tests for one of those services, but I just realised the fundamental flaw here with such tests. I only have 1 application running, but I need several. This is quite a serious flaw I should have seen before.

Anyone else tried integration testing event driven distributed services? I imagine all I can do is stub the message broker...

Comments
  • 0
    Our setup is similar but without the broker. We test against a stable (test) version of the other service which is always up.
  • 2
    Mock the other services.
  • 0
    @dan-pud in memory database so that's not possible
  • 0
    @craig939393 confused.

    Isn't the whole test then a paradoxon?

    As you're testing not the ""real"" situation, but rather an optimal state?
  • 0
    @IntrusionCM I don't understand what you mean. See .net integration testing.

    I have replaced I/O but that's it. So file storage, log sinks, 3rd part integrations, database, all replaced so I can test as much of my entire service as possible without actually telling a 3rd party company that a purchase has been made.
  • 0
    @craig939393
    I don't understand. If your service has an in memory database it shouldn't affect other running services. Do the other services depend on the same database? If that's true I would highly suggest getting a competent architect to sort that out.
    If that's not true my suggestion above should still hold.
  • 0
    @dan-pud right you noticed the database problem I didn't think to mention. I joined a new team and it's literally a big ball of mud that I'm trying to be the architect for, but I haven't come into this problem of testing a big ball of mud before, and I'm not making changes without tests. It's also not really event driven, you could say it's a barstardised event driven. I haven't tested such a setup before.
  • 0
    I like your reference to big ball of mud 😀
    I guess start with the dependencies, try and map out the flow of information.
    If everything is using the same database it's essentially a monolith though so it might be helpful to think of it in those terms. Monoliths aren't terrible. It's a great place to start from.
    Good luck!
Add Comment