5 ms·

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

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.

kkapelon 9y ago
>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".
- nwatson 9y ago
  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.
  - kodr 9y ago
    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.
    - nwatson 9y ago
      With Docker I can run my E2E "offline".
      - joshuamorton 9y ago
        If you're touching real data, your test isn't offline.
        AstralStorm 9y ago
        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.
  - bsandert 9y ago
    it('sends an email to the user', ...)
    - nwatson 9y ago
      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.
- w4tson 9y ago
  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
bluGill 9y ago
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.
alien_at_work 9y ago
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.
- kqr 9y ago
  Why can't a unit test work on the unit "package"? Or an integration test work on the integration of multiple methods?

kkapelon 9y ago

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

nwatson 9y ago
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.
- kodr 9y ago
  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.
  - nwatson 9y ago
    With Docker I can run my E2E "offline".
    - joshuamorton 9y ago
      If you're touching real data, your test isn't offline.
      - AstralStorm 9y ago
        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.
- bsandert 9y ago
  it('sends an email to the user', ...)
  - nwatson 9y ago
    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.
w4tson 9y ago
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

bluGill 9y ago

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.

alien_at_work 9y ago

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.

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