Welcome to the MongoDB Community Forums. I understand that you’re attempting to mock parts of the MongoDB .NET/C# Driver. A widely accepted testing practice is “Don’t mock what you don’t own”. In other words, don’t mock third-party dependencies, but only your own abstractions. In your example, you should mock AlertGetByStationIdInternalAsync (your code), not IAggregateFluent<TResult> (driver code).
Using this strategy you can integration test AlertGetByStationIdInternalAsync, which would talk to the database and use the actual driver implementation. You can then separately unit test your code that depends on AlertGetByStationIdInternalAsync without talking to a database or setting up hard-to-configure error conditions. I would recommend full system tests that exercise the full stack, but you wouldn’t have to test all the edge cases (such as your database being offline or containing unexpected data or other errors).
I hope that helps in developing your testing strategy.
For code that uses AlertGetByStationIdInternalAsync, you should mock AlertGetByStationIdInternalAsync itself. To test AlertGetByStationIdInternalAsync, you should integration test that against an actual MongoDB database.
The problem with trying to mock the driver is that you must make assumptions about the internal implementation of the driver and the underlying MongoDB cluster. This makes your test suite extremely brittle and unreliable. For example let’s say you do mock IMongoCollection<T> and all the associated types, but you use a server feature not supported by your current MongoDB version. Your mocked tests would pass - because you’ve made assumptions about return values - but the actual query would fail in production.
There are many mocking frameworks available that would allow you to mock IMongoCollection<T> and its associated interfaces. Even though it is possible, mocking dependencies that you don’t own is a code smell that will result in a brittle test suite. I strongly encourage you to integration test your code that directly interacts with the .NET/C# Driver rather than attempting to unit test it.