Closed dejandjenic closed 11 months ago
Name | Link |
---|---|
Latest commit | 10ee8465ba15b3279f142fe700fc0576c9f698e8 |
Latest deploy log | https://app.netlify.com/sites/testcontainers-dotnet/deploys/6506a6db5915190008bbe5e3 |
Deploy Preview | https://deploy-preview-988--testcontainers-dotnet.netlify.app/modules |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
i pushed new changes to resolve comments made to PR, i didn't resolve comments themselves unsure what are practices here. if required i can do that.
I can do a push with renaming tommorow, gcloud naming is similar to java containers but dotnet containers have different setup. E. G. Azure is not single module. What ever you decide. I plan to push pubsub in aonther pr also
Hmm, I think it depends on how often these containers may be used together and whether they share common configurations. @eddumelendez , based on your experience with Java, do you think it makes sense to publish them as separate modules or within a single one (the GCloud emulators)? Any opinion regarding the name (FirestoreContainer
vs. FirestoreEmulatorContainer
)?
basically they don't share configuration at all, for usage point it depends on what are you testing e.g. in my company we use several levels of testing
if containers are used in unit test then responsibility of certain class is unlikely (should not) involve multiple concerns, repository, service ... should work with firestore or pubsub or bigquery ... if containers are used for functional (integration) testing via testserver then at server setup it might need to setup entire infrastructure which could need setting multiple containers (here module approach would help)
IMHO i would stick to general testcontainers dotnet design which is one container per service, but this is up to you
on naming i would go with FirestoreContainer , we all know it is an emulator :-)
I think it depends on how often these containers may be used together and whether they share common configurations.
Testcontainers modules based on google-cloud-cli
image don't share any config. They are group based on the concept of the GCP services.
The relationship between modules and implementation shouldn't be always 1:1. In the future, a confluentic
module can be shared providing Testcontainers implementations for schema registry
, kafka
, ksqldb
and others. The same for percona
database which offers images for mysql
, postgres
Feedback about this topic is welcome.
Any opinion regarding the name (FirestoreContainer vs. FirestoreEmulatorContainer)?
FirestoreContainer
is ok 👍🏽
What does this PR do?
Why is it important?
Related issues
-