Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How are you promoting this? #11

Open
jzabroski opened this issue Dec 27, 2019 · 8 comments
Open

How are you promoting this? #11

jzabroski opened this issue Dec 27, 2019 · 8 comments

Comments

@jzabroski
Copy link
Contributor

This seems to be the most mature library for running docker integration tests in .NET, but I find nobody is talking about this in the .NET Community.

@Deffiss
Copy link
Owner

Deffiss commented Jan 9, 2020

Hello, I've been talked about this a year ago on a big conference DotNext 2018 in Moscow (https://2018.dotnext-moscow.ru/en/2018/msk/talks/3ymcx4gfcesekaw2qwgeas/). Also I am constantly pushing this approach on my projects and inside my company. Apart from that there is no other efforts. Do you think it is worth to promote?

@jzabroski
Copy link
Contributor Author

Yes. TestContainers-DotNet is a total disaster. You seem to be way ahead of them and the only disadvantage you have is you don't have the TestContainers brand name recognition.

Love the use of async/await - it's brilliant and simplifies things like stupid things people do in docker-compose.yml files, like using https://github.com/ufoscout/docker-compose-wait so that an ASP.NET Core web server docker container running entity framework waits for a database server to start and pass health check before starting the web server container.

@Deffiss
Copy link
Owner

Deffiss commented Jan 10, 2020

Yeah, waiters are very useful feature, but there is another one called containers re-usage that allows you to run your containers only after first tests execution and then instead of re-creating them for each test run the library just can drop all the data. That saves lots of seconds if you have such containers like Elasticsearch (~30 secs to start) or MSSQL (~40 secs to start).

@jzabroski
Copy link
Contributor Author

Yes, and the ability to destroy a container to simulate a crash.

@jzabroski
Copy link
Contributor Author

When you really think about it, there is no reason you can't replace docker-compose with TestEnvironment.Docker - it just needs a way to wake back up on system restart. The way docker-compose does this, I think, is through using a yaml config file. Maybe it has other tricks, but the argument for docker-compose is it can "just go" on startup. But that is not that a clever trick. Just wrap TEstEnvironment.Docker referencing project in TopShelf and expose as a Windows Service.

@jzabroski
Copy link
Contributor Author

Yes, and the ability to destroy a container to simulate a crash.

@Deffiss Curious if your recent PR #13 was provoked by this comment 🗡

@Deffiss
Copy link
Owner

Deffiss commented Jan 13, 2020

Well, if somebody from community is interested in my work then it always motivates me..

@jzabroski
Copy link
Contributor Author

jzabroski commented Jan 13, 2020

I mentioned it to David Fowler at Microsoft since he just created Micronetes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants