Thread

1. goostavos · 1790548148 · focus · HN ↗

   These miss the point of integration testing (in my Humble opinion). Integration tests are valuable because they get around the problem of mocking. They let you reach out into the foreign thing you use and see if it behaves the way you expect it to. If you replace the real thing with a fake thing, you are, well, by definition, not learning anything about the real thing. It's the subtle behaviors and quirks of real services that often cause the most problems. (It's why testing the DDB Local often hides the painful eventual consistency problems you see with DDB proper.)

   My $0.02: just use the AWS SDK to spin up real infrastructure on demand. You can provision SQS in < 10ms. Buckets in <100ms. DDB can take upwards of 30 seconds to a minute if you're adding GSIs, but it's a very small tax in exchange for the confidence it brings. (People often balk at this idea when they first hear it, but give it a shot! I have stamped out many a bug thanks to being able to bounce ideas off real infra.)

   1. joshribakoff · 1790553664 · focus · HN ↗

      You seem to be mixing up integration tests with end to end tests.
   2. lucas_vieira · 1790560007 · focus · HN ↗

      [dead]

   3. najmbajwa123 · 1790591913 · focus · HN ↗

      I think what actually pushes people back is cleanup not speed. Real infra can give you things you actually want to test.

      1. goostavos · 1790738498 · focus · HN ↗

         Cleanup is indeed an art when you go with this approach. Namespacing helps a lot, as well as little things like randomizing individual queue names such that test run B never knows that infra from run A (that may still be hanging around from a failed cleanup) exists.

Unofficial Hacker News client; not affiliated with Y Combinator.