This makes no sense tho. Simple example, your code needs to reach into Cosmos / DynamoDB, why mock this service when u can get so much wrong by assuming how things work?

Mocking doesn't mean you have to reimplement the fully featured service. In the simplest form your internal library which calls out to Cosmos is mocked, the mock records the request parameters and returns ok, and the test verifies that the expected data was passed in the call.

Then you're testing the implementation and need to change the test and mocks every time the implementation changes.

Making stuff quicker is a good reason to mock stuff. So is not hitting real network services. But, in all cases, the best thing is to avoid mocking if possible.

Why do you care how Cosmos or DynamoDB or any other dependency is implemented? You only need to mock the interface to these services. Their internal code can change every day without affecting your tests.

And if you want to catch potential changes in Cosmos that modify the behavior of your own service, that isn't the purpose of unit tests.

I want to be able to update to the latest version of DynamoDB (or something else - not every dependency is as stable as DynamoDB) and know that all of my code that calls it still works.