31–40 of 260 posts
Testcontainers aren't even compatible with kubernetes, that's a tool from the past.
I find integration tests that exercise actual databases/Elasticsearch/Redis/Varnish etc to be massively more valuable than traditional unit tests. In the past I've gone to pretty deep lengths to do things like spin up a new Elasticsearch index for the duration of a test suite and spin it down again at the end.
It looks like Testcontainers does all of that work for me.
My testing strategy is to have as much of my application's functionality covered by proper end-to-end integration-style tests as possible - think tests that simulate an incoming HTTP request and then run assertions against the response (and increasingly Playwright-powered browser automation tests for anything with heavy JavaScript).
I'll use unit tests sparingly, just for the bits of my code that have very clear input/output pairs that afford unit testing.
I only use mocks for things that I don't have any chance of controlling - calls to external APIs for example, where I can't control if the API provider will be flaky or not.
Wait what? They think you don't need unit tests because you can run integration tests with containers?
It's trivial to set up a docker container with one of your dependencies, but starting containers is painful and slow.
Earlier quoted context omitted.
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…
> *Paragraph one.*
> *Paragraph two. Etc.*
Which produces the desired effect:
> Paragraph ‘one’.
> Paragraph two.
(To use a * in a paragraph that’s italic-wrapped, backslash it.)
Testcontainers aren't even compatible with kubernetes, that's a tool from the past.
> No more need for mocks or complicated environment configurations. Define your test dependencies as code, then simply run your tests and containers will be created and then deleted. Wait what? They think you don't need unit tests because you can run integration tests with containers? It's trivial to set up a docker container with one of your dependencies, but starting containers is painful and slow.
Earlier quoted context omitted.
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"?
Most people will say something like for unit tests you should test your functions by passing the state as parameters to test. I'm going to call this "outside in" loose coupling.
Mocking is for the inverse. When you want to test a unit of code that is calling some other outside unit code. Its really not any different just "inside out".
So imo with DI you gain loose coupling through dependency inversion. But because of dependency inversion you need to mock instead of passing state as params.
So I think if you are injecting a mocked stub this is still loose coupling because you are testing against its interface.
You're still passing state through your test but its coming from inside instead of outside, hence the mock.
Another way I have thought about this is: framework (framework calls you) vs library (you call library).
Frameworks naturally lend themselves to a more mock way of testing. Library lends itself to a more traditional way of testing.
Testing something that accepts a callback is also essentially a mock.
I hope that thought made sense.
Its pretty much required when you want to setup/teardown in between tests though. This just usually isnt the case for me.
Running integration tests are significantly more complicated to write and take longer to run.
There is also race conditions present that you need to account for programmatically.. Such as waiting for a db to come up and schema to be applied. Or waiting for a specific event to occur in the daemon.
That being said, this looks like a decent start. One thing that seems to be missing is the ability to tail logs and assert specific marks in the logs. Often you need to do an operation and wait until you see an event.