Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Testcontainers

testcontainers.com

Post reply on HN
Print view View original

201–210 of 260 posts

Re: Testcontainers

#201

Post by JackFr »

imiric wrote: post #135
CobrastanJorji wrote: post #89

Earlier quoted context omitted.

I love integration tests. You know why? Because I can safely refactor all I want! Unit tests are great, but if you significantly refactor how several classes talk to each other, and each of those classes had their own, isolated unit tests that mocked out all of the others, you're suddenly refactoring with no tests. But a black box integration tests? Refactor all your code, replace your databases, do whatever you want…

I've heard this aversion to unit tests a few times in my career, and I'm unable to make sense of it. Sure, integration tests "save" you from writing pesky unit tests, and changing them frequently after every refactor. But how do you quickly locate the reason that integration test failed? There could be hundreds of moving parts involved, and any one of them malfunctioning, or any unexpected interaction between them, c…

> Sure, integration tests "save" you from writing pesky unit tests, and changing them frequently after every refactor.

The DB migration has "ADD COLUMN rateLimit INT"

The application class member is annotated with "@Column(name=”ratelimit”, nullable=true)"

The failure is at the interface between the app and the DB. What testcontainers does is allow you to write a quasi-unit test (not a truly full-blown integration test, but testing a small piece of functionality) across the boundary of two components. I am not aware of a way to reasonably unit test for this error. That might just be me -- seriously if there is a tried strategy for unit testing things like this I'd love to know it.

Re: Testcontainers

#202

Post by arbll »

xyst wrote: post #188
perfectspiral wrote: post #179

Earlier quoted context omitted.

Agreed and in my experience libraries like this perpetuate that anti-pattern. Inexperienced developers think because there's a library that enables it, it must be OK, right?

Low bid contractors will probably use this library to pump their code coverage numbers. Some of the shit shops I have worked at that hired lowest bid contractors have done some shady shit to meet “management expectations”.

If "management expectations" are based on code coverage numbers low bid contractors are probably the least of your worries

Re: Testcontainers

#205

Post by jackcviers3 »

et1337 wrote: post #80

I looked at testcontainers and ended up rolling my own version. One issue I had is that Docker is a very leaky abstraction. I needed to write one test and have it run in all these scenarios: - on a Mac - on a Linux VM - in a Docker container on a Linux VM, with a Docker socket mounted The networking for each of these is completely different. I had to make some opinionated choices to get code that could run in all cas…

Many of the Mac networking specifics have become less of a problem. I use Rancher Desktop, which uses the correct virtualization framework based on OSX versions and allows you to customize the lima and virtual machine provisioning scripts so that you don't have cross-platform headaches like this (for the most part). Also runs kubernetes locally out of the box so you can test app deployments without waiting around for resources to free up on your shared dev cluster. Newest versions have almost everything Docker Desktop has. Highly recommend if you are on mac.

Re: Testcontainers

#208

Post by paxys »

jchw wrote: post #92
paxys wrote: post #50

Earlier quoted context omitted.

FYI Docker already has a RESTful API, and programming container start/stop is trivial to do in any language. I haven't used Testcontainers before, and can kinda see the utility, but IMO it really isn't worth it in the long term to take on a new external dependency for a bit of code that (1) is a critical part of the team's development and release process and (2) can be written in-house in maybe an hour.

> it really isn't worth it in the long term to take on a new external dependency for a bit of code that (1) is a critical part of the team's development and release process and (2) can be written in-house in maybe an hour. This seems to be quite a contradiction. If it's so easy to just write from scratch, then why would it be scary to depend on? Of course, it's not that easy to write from scratch. You could make a pr…

This thought process taken to the extreme is what results in half the internet depending on leftPad and isOdd to function. Open source is great, but there is a difference between providing a utility vs adding needless layers of abstraction. It is the responsibility of the developer to figure out which is which rather than reach for the package manager for every task in front of them.

In this case, like I said earlier Docker already has a RESTful API. You don't need to replicate the entire feature set of Testcontainers, just make a couple of HTTP calls in your language of choice to achieve the exact same outcome.

Re: Testcontainers

#209

Post by jackcviers3 »

domano wrote: post #155

I dont understand how this is better than a docker-compose.yml with your dependencies, which plays nicer with all other tooling. Especially if there are complex dependencies between required containers it seems to be pretty weak in comparison. But i also only used it like 5 years ago, so maybe things are significantly better now.

Testcontainers integrates with docker-compose [1]. Now you can run your tests through a single build-tool task without having to run something else and your build. You can even run separate compose files for just the parts your test touches.

1. https://java.testcontainers.org/modules/docker_compose/

Re: Testcontainers

#210

Post by plagiarist »

Shaanie wrote: post #176
collyw wrote: post #147

Earlier quoted context omitted.

[flagged]

Which is a perfectly fine counter-argument if you are, in fact, not going it right. If you say you're doing continuous deployment because you deploy every Tuesday evening, it's perfectly fair to point out that that's not continuous deployment. Of course, you should follow it up by explaining why as well, but many companies don't actually follow the agile principles.

This is a digression from the original topic, but my criticism of agile is in fact that nobody is doing it right. If the majority of companies that attempt it end up just wasting extra time, the process itself is broken.
Post reply on HN