Hacker News Reader

Comment by d_burfoot | Hacker News Reader

I don't understand why people are so enamored of the distinction between "unit" tests and "integration" tests. That dichotomy has never seemed useful to me. In my mind the relevant distinction is speed. There's one fast test suite that you run before every code commit, and another slower suite that you run every night on a cloud instance or testing machine, and review the results in the morning. The fast/slow distinction is roughly comparable to the unit/integration distinction, but I don't have any problem with testing a DB interaction in the fast suite - and in fact consider it to be a good practice - if the interaction is fast enough. In general the fast suite should check as much as possible within the constraint of needing to be fast.

View on HN

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

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

It's very simple: Unit tests test a specific "unit" (i.e. in an OO language, that's a class) and integration tests test the ingration of multiple units.

In OO languages, I personally prefer unit tests with all dependancies stubbed or mocked out to verify the interface of that specific unit or component.

Why can't a unit test work on the unit "package"? Or an integration test work on the integration of multiple methods?

I'm with you. I find my tests using a real database or a real file system run in .001 seconds or less, so who cares. Of course I'm in an embedded system, our production database is sqlite: we don't have to worry about spinning a database connection up.

Reply on news.ycombinator.com