Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
dan-pud8594yOur setup is similar but without the broker. We test against a stable (test) version of the other service which is always up.
-
@craig939393 confused.
Isn't the whole test then a paradoxon?
As you're testing not the ""real"" situation, but rather an optimal state? -
Crost41084y@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. -
dan-pud8594y@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. -
Crost41084y@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.
-
dan-pud8594yI 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!
Related Rants
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...
question
.net
event driven
integration testing