Hacker News Reader

Comment by kkapelon | Hacker News Reader

>The fast/slow distinction is roughly comparable to the unit/integration distinction

I think you answered the question yourself. Speed is also shown in the table that defines the types of tests.

You can name the categories foo tests and bar tests if you wish.

Anti-pattern 1 - is companies that have only the "fast suite" you are talking about and anti-pattern 2 is companies that have only the "slower suite".

View on HN

I'd prefer that all testing be done with live data in a real database ... maybe not at the very beginning but as soon as practicable. I came into a project recently with so many issues around differences between real data and assumed data, and unrealistic assumptions about real data that it's been hugely painful, with lots of back and forth between Dev and QA and Ops. With Docker now there's no excuse for not setting up soon in a project's lifecycle a realistic environment (infrastructure topology-wise) with real data on development and QA laptops.

With this you still have fast and slow perhaps, but everybody can run all but the most extreme scaling tests.

That's E2E test. What's interesting with unit tests is that you can run them locally, offline. They are fast enough so that you can run them and see if you broke anything. If your tests take too much time to start or relies on a live env (which may be down or broken), you'll spend more time for maybe nothing.

With Docker I can run my E2E "offline".

If you're touching real data, your test isn't offline.

Not true. You might be touching local sample of real or realistic data. It does not need to be static either.

The performance of such a test is still a problem.

    it('sends an email to the user', ...)

An automated test causes the tested product to send an email to the user? So ... my docker local deployment has a DNS server with the proper MX records, an SMTP server to receive the emails, an IMAP server to expose and serve up the received emails, and the test running on my macOS can check the entire flow. No need to even have my laptop connected to any network for this test to run in its fullest.

It’s more than this. The difference is important. Employed in the right areas like the article suggests they can be an effective weapon against bugs creeping into data access, messaging or web client components.

The speed at which they run is their side effect. It’s possible to write slow running unit tests

Reply on news.ycombinator.com