undefined | Better HN

0 pointsJackFr2y ago0 comments

> 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.

0 comments

imiric2y ago

That's an _integration_ failure. We're talking about testing two entirely different things here. Of course you shouldn't expect to test integration scenarios in unit tests.

But you also shouldn't expect to test all unit scenarios in integration tests. This is what the "trophy testing" model advocates for. That somehow unit tests are not needed if you have thorough integration tests, which is entirely false.

They test the application at different layers, because they're meant to ensure behavior to different types of users. They're both useful for catching bugs and unexpected behavior, and they're meant to complement each other.

j / k navigate · click thread line to collapse

0 comments

imiric2y ago

That's an _integration_ failure. We're talking about testing two entirely different things here. Of course you shouldn't expect to test integration scenarios in unit tests.

j / k navigate · click thread line to collapse