Unit test suppose to be fast. Especially during coding. I wonder how this is necessary & not affecting the test feedback speed
This is for integration tests.
Testcontainers
21–30 of 260 posts
Re: Testcontainers
#22Earlier quoted context omitted.
Typically you mock them in unit tests.
Seems like such a test would be strictly less useful than a test that runs against the real dependeny.
But vastly faster.
A good rule of thumb for a unit test is that you should be able to run it a few thousand times in a relatively brief period (think: minutes or less) and it shouldn't ever fail/flake.
If a unit test (suite) takes more than a single digit number of seconds to run, it isn't a unit test. Integration tests are good to have, but unit tests should be really cheap and fundamentally a tool for iterative and interactive development. I should be able to run some of my unit tests on every save, and have them keep pace with my linter.
Re: Testcontainers
#23Re: Testcontainers
#24Earlier quoted context omitted.
Typically you mock them in unit tests.
I've rarely found this to be worth it, for the effort required for a proper mock, in a complex system. I've seen most people mock in ways that are so superficial that it's basically a no-op.
Mocks are a contentious topic as you've probably guessed. In my opinion they're a sign of coupled code, you should be able to hit very high coverage without a single mock, but if you're a dev in an org that tracks code coverage you'll probably end up writing a fair number of them since the odds are high you'll be consuming coupled code.
Re: Testcontainers
#25I was intrigued to see that they have PyPI packages for a ton of different things - like https://pypi.org/project/testcontainers-postgres
That wheel file is only 2.9KB, so I grabbed a copy to see how it works. I've put the contents in a Gist here: https://gist.github.com/simonw/c53f80a525d573533a730f5f28858...
It's pretty neat - it depends on testcontainers-core, sqlalchemy and psycopg2-binary and then defines a PostgresContainer class which fires up a "postgres:latest" container and provides a helper function for getting the right connection URL.
Re: Testcontainers
#26Earlier quoted context omitted.
Seems like such a test would be strictly less useful than a test that runs against the real dependeny.
But vastly faster. A good rule of thumb for a unit test is that you should be able to run it a few thousand times in a relatively brief period (think: minutes or less) and it shouldn't ever fail/flake. If a unit test (suite) takes more than a single digit number of seconds to run, it isn't a unit test. Integration tests are good to have, but unit tests should be really cheap and fundamentally a tool for iterative and…
Testcontainers don't typically add more than a few seconds to a suite though. They are very fast.
Re: Testcontainers
#27Testcontainers aren't even compatible with kubernetes, that's a tool from the past.
Re: Testcontainers
#28I didn't quite understand why this was made. We create our local test environments using docker-compose, and so I read: > Creating reliable and fully-initialized service dependencies using raw Docker commands or using Docker Compose requires good knowledge of Docker internals and how to best run specific technologies in a container This sounds like a abstraction over docker-compose, which lets you define your docker…
Going to the sections for language interactions shows a lot more stuff, e.g., the first full go example: https://testcontainers.com/guides/getting-started-with-testc... Shows how you can embed the declaration of db for testing in a unit test: > pgContainer, err := postgres.RunContainer(ctx, > testcontainers.WithImage("postgres:15.3-alpine"), > postgres.WithInitScripts(filepath.Join("..", "testdata", "init-db.sql")),…
On Hacker News you need to indent code examples with four spaces - like this:
pgContainer, err := postgres.RunContainer(
ctx, testcontainers.WithImage("postgres:15.3-alpine"
),
postgres.WithInitScripts(filepath.Join("..", "testdata", "init-db.sql")),
postgres.WithDatabase("test-db"),
postgres.WithUsername("postgres"),
postgres.WithPassword("postgres"),
testcontainers.WithWaitStrategy(
wait.ForLog("database system is ready to accept connections").Re: Testcontainers
#29Pulling up infra to run unit tests is an anti-pattern. This is a great tool for integration tests, though.
honest question: how are you writing integration tests? We are writing these as separate test suite often with the same test style. And in this scenario testcontainers are very valuable.
Re: Testcontainers
#30Earlier quoted context omitted.
I've rarely found this to be worth it, for the effort required for a proper mock, in a complex system. I've seen most people mock in ways that are so superficial that it's basically a no-op.
Mocks are a contentious topic as you've probably guessed. In my opinion they're a sign of coupled code, you should be able to hit very high coverage without a single mock, but if you're a dev in an org that tracks code coverage you'll probably end up writing a fair number of them since the odds are high you'll be consuming coupled code.
If you have a dependency like a third party API (or even internal code), and you write an API client, then depend on that client, would it be considered couple code?
In such cases, if I am using dependency injection and creating a (stub?) versions of that client which returns a hardcoded or configured output, would that be considered a mock? OR would this be OK and not "coupled"?