Ensure CosmosDB Components have enough testing

[eerhardt]

359 added support for CosmosDB components. We should ensure these components have all the necessary test coverage - for example logging and tracing tests.

The other components have 2 modes:

• Can Connect to server
• Can't Connect to server (typically this is run in CI)

I didn't see any tests that actually connect to a server. We should see what it takes to enable that class of tests.

cc @Pilchie

[stbau04]

@eerhardt By the tests that actually connect to a server you mean the stuff in tests/testproject? I think i would have some time to add further tests

[eerhardt]

By the tests that actually connect to a server you mean the stuff in tests/testproject?

@mitchdenny added a test in https://github.com/dotnet/aspire/pull/1668 for this.

My original intention was to follow the same pattern as we do in the other Azure components - if the test is configured to a service that can be connected to, it runs more tests.

For example, for Storage Blobs:

https://github.com/dotnet/aspire/blob/e8288d729880141c062cfea474b59239895732b4/tests/Aspire.Azure.Storage.Blobs.Tests/ConformanceTests.cs#L21

https://github.com/dotnet/aspire/blob/e8288d729880141c062cfea474b59239895732b4/tests/Aspire.Azure.Storage.Blobs.Tests/ConformanceTests.cs#L122-L132

[stbau04]

@eerhardt Ok that seems quite logical, but where should the server run? When looking at the Storage blob it seems like it connects to this service: https://aspirestoragetests.blob.core.windows.net/ MongoDb on the other hand is connecting to something local: mongodb://root:password@localhost:27017/test_db

Why is one of them running locally while the other uses a remote connection? What should be used for the cosmosdb? As there is an emulator (which is used in TestProject) i would guess it should be running locally? This leads to my next question: If it should run locally, where should it be started? I couldn't figure that out looking at the other tests

[eerhardt]

Getting component tests running against a local container / emulator is something that has been on our list. Weare actively working on figuring out how to do more and better testing here.

For this, my hope is that we can spin the local emulator up at the beginning of the tests and then run the suite of tests hitting it. However we don't have the test infrastructure to do this easily, yet.

[stbau04]

@eerhardt Isn't there an issue for that? I think i rember that i've read something about resuing parts of the app host logic or something similar for this?

Should i spend time on tests for the cosmosdb now? Or should we wait until the infrastructure is created?

[eerhardt]

I think the CosmosDB tests can be written now like the rest of the tests are. That part doesn't need to wait until the infrastructure is created. The tests can follow the existing pattern.

[stbau04]

@eerhardt Where should the cosmosdb server be running? Locally as in the mongodb tests or some remote server as in the storage blob tests?

[eerhardt]

For now, I'd do it as a remote server as in the storage blob tests.

[stbau04]

@eerhardt Ok, but what server should we use?

[eerhardt]

@eerhardt Ok, but what server should we use?

We started using "Test Containers" - See https://github.com/dotnet/aspire/pull/2345. Can we use the local CosmosDB emulator using test containers?

[stbau04]

@eerhardt I tried adding the Testcontainers.CosmosDb to the test project. This breaks all nuget-Dependencies:

• All dependencies were marked in the solution explorer (but no actual warnings were shown)
• The usings in the code were shown as unused and the corresponding classes were not found

Did this also happen at the RabbitMQ tests?