181–190 of 260 posts
I did not come in here expecting to read such effusive praise for testcontainers. If you’re coming from a place where docker wasn’t really a thing I can see how it looks beautiful. And in a fair amount of use cases it can be really nice. But if you want it to play well with any other containerized workflow, good freaking luck. Testcontainers is the library that convinced me that shelling out to docker as an abstracti…
Earlier quoted context omitted.
Why not use docker compose, bring up your infra in one container, your application in a second and your tests access it the application from a third.
Because you don't have to muck around with docker-compose. I guess some people might find that more attractive.
Earlier quoted context omitted.
Why'd you run them in kubernetes? Seems like extreme overkill for launching a short lived container for an integration test. What could kubernetes possibly add to that?
Because we are a big company and would like to utilize resources better. We also want homogeneity in tech when possible (we already heavily use kubernetes, we don't want to keep docker hosts anymore). Teams of testers need to be accounted in terms of resource quotas and RBAC. What exactly do you see as an overkill in wanting to run short-lived containers in kubernetes rather than in docker (if we already have kuberne…
One small note: test run time will probably increase. If a person has an outdated computer, I suspect they will have a hard time running the IT suite. Especially if it’s a complicated system with more than one dependency.
Earlier quoted context omitted.
To be honest, it doesn't sound like you really had a good use case for Testcontainers anyways. Where it excels the most is in just pulling in some external containers, especially databases, e.g. PostgreSQL and Redis, directly in your test harness. In those cases, it works well.
Our use-case was redis servers, one of your supposedly good use-cases for testcontainers. I didn't mention, but the testcontainer code also preferred to add that network io to the actual test runtime, which made measuring the test's performance harder, and meant we couldn't as safely cache the test's results. The bazel version made it easy to build the test's dependency as part of the test compilation process (as it…
Pulling up infra to run unit tests is an anti-pattern. This is a great tool for integration tests, though.
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?
Earlier quoted context omitted.
This advice is so misguided that I'm concerned for our industry it's getting so much traction. > You really want to avoid testing implementation details because it doesn't give you very much confidence that your application is working and it slows you down when refactoring. You should very rarely have to change tests when you refactor code. Unit tests don't need to test implementation details. You could just as well…
If by "smallest pieces of the system" you mean something like individual classes then you are definitely testing implementation details. Whenever you change a method's parameters in one of those internal classes you'll have unit tests breaking, even though you're just refactoring code. Unit testing at the smallest piece level calcifies the codebase by making refactors much more costly.
If your classes properly specify access modifiers, then no, you're not testing implementation details. You're testing the public interface. If you think you're testing implementation details, you probably have your access modifiers wrong in the class.
Earlier quoted context omitted.
You might be interested in the ‘testing trophy’ as an alternative to the traditional pyramid. https://kentcdodds.com/blog/write-tests
This advice is so misguided that I'm concerned for our industry it's getting so much traction. > You really want to avoid testing implementation details because it doesn't give you very much confidence that your application is working and it slows you down when refactoring. You should very rarely have to change tests when you refactor code. Unit tests don't need to test implementation details. You could just as well…
In this scenario unit tests would not add value over integration tests when looking for the existence of errors.
But: In a bigger project you don't only want to know "if" there is a problem, but also "where". And this is where the value of unit tests comes in. Also you can map requirements to unit tests, which also has some value (in some projects at least)
edit: now that I think about it, you can also map requirements to e2e tests. That would probably even work much better than mapping them to unit-tests would.