4 ms·

If you don't write unit tests, how do you know something works? Just manual QA? How long does that take you relative to unit tests? How do you know if something

If you don't write unit tests, how do you know something works? Just manual QA? How long does that take you relative to unit tests? How do you know if something broke due to an indirect change? Just more manual QA? Do you really think this is saving you time?

tsimionescu 1y ago
You can write many other other kinds of automated tests. Unit tests are rarely worth it, since they only look at the code in isolation, and often miss the forest for the trees if they're the only kind of test you have. But then, if you have other higher level tests that test your components are working well together, they're already implicitly covering that each component individually works well too - so your unit tests for that component are just duplicating the work the integration tests are already doing.
- skydhash 1y ago
  Sometimes you really need to ensure that something is a tree. And you do not need the whole forest around for that. Sure you can’t have an adventure with only a tree. But if you need a tree, you need to make sure someone don’t bring a concrete tree sculpture.
deleted 1y ago
[deleted]
troupo 1y ago
> If you don't write unit tests, how do you know something works? Integration tests. Unlike unit tests they actually test if something works.
- yakshaving_jgt 1y ago
  This is utter nonsense.
  - troupo 1y ago
    Unit tests test units in isolation. Integration tests test that your system works. Testing how a system works covers the absolute vast majority of functionality you'd test with unit tests because you will hit the same code paths, and test the same behaviours you'd do with unit tests, and not in isolation. This is a joke, but it's not: https://i.sstatic.net/yHGn1.gif https://i.sstatic.net/yHGn1.gif
    - yakshaving_jgt 1y ago
      I have been doing TDD for over a decade, and I don’t know why you’re trying to explain the basics to me. Yes, you can exercise the same code paths with integrated tests as you might with unit tests. There are multiple approaches to driving integrated tests, from the relatively inexpensive approach of emulating a HTTP env, to something more expensive and brittle like Selenium. You could also just test everything with manual QA. Literally pay some humans to click through your application following a defined path and asserting outcomes. Every time you make a change. Obviously all of these have different costs. And obviously, testing a pure function with unit tests (whether example based or property based) is going to be cheaper than testing the behaviour of that same function while incidentally testing how it integrates with its collaborators.
      - troupo 1y ago
        > You could also just test everything with manual QA. Literally pay some humans to click through your application following a defined path and asserting outcomes. Every time you make a change. How to see if someone is arguing in bad faith? Well, they pretend that reductio ad absurdum is a valid argument > Obviously all of these have different costs. And obviously, testing a pure function with unit tests (whether example based or property based) is going to be cheaper than testing the behaviour of that same function while incidentally testing how it integrates with its collaborators. Let's see. A single scenario in an integration test: - tests multiple code paths removing the need for multiple unit tests along that code path - tests externally observable behaviour of the app/api/system is according to spec/docs - tests that all units (that would otherwise be tested in isolation from each other) actually work together This is obviously cheaper. Programmer (the expensive part) has to write less code, the system doesn't suddenly break because someone didn't wire units together (the insanely expensive part, 'cause everything was mocked in tests; unironically true story that hammered the final nail in the coffin of unit tests for me). By the way, here's what Kent Beck has to say about unit tests: https://stackoverflow.com/a/153565 https://stackoverflow.com/a/153565 --- start quote --- I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence --- end quote ---

tsimionescu 1y ago

You can write many other other kinds of automated tests. Unit tests are rarely worth it, since they only look at the code in isolation, and often miss the forest for the trees if they're the only kind of test you have. But then, if you have other higher level tests that test your components are working well together, they're already implicitly covering that each component individually works well too - so your unit tests for that component are just duplicating the work the integration tests are already doing.

skydhash 1y ago
Sometimes you really need to ensure that something is a tree. And you do not need the whole forest around for that. Sure you can’t have an adventure with only a tree. But if you need a tree, you need to make sure someone don’t bring a concrete tree sculpture.

deleted 1y ago

[deleted]

troupo 1y ago

> If you don't write unit tests, how do you know something works? Integration tests. Unlike unit tests they actually test if something works.

yakshaving_jgt 1y ago
This is utter nonsense.
- troupo 1y ago
  Unit tests test units in isolation. Integration tests test that your system works. Testing how a system works covers the absolute vast majority of functionality you'd test with unit tests because you will hit the same code paths, and test the same behaviours you'd do with unit tests, and not in isolation. This is a joke, but it's not: https://i.sstatic.net/yHGn1.gif https://i.sstatic.net/yHGn1.gif
  - yakshaving_jgt 1y ago
    I have been doing TDD for over a decade, and I don’t know why you’re trying to explain the basics to me. Yes, you can exercise the same code paths with integrated tests as you might with unit tests. There are multiple approaches to driving integrated tests, from the relatively inexpensive approach of emulating a HTTP env, to something more expensive and brittle like Selenium. You could also just test everything with manual QA. Literally pay some humans to click through your application following a defined path and asserting outcomes. Every time you make a change. Obviously all of these have different costs. And obviously, testing a pure function with unit tests (whether example based or property based) is going to be cheaper than testing the behaviour of that same function while incidentally testing how it integrates with its collaborators.
    - troupo 1y ago
      > You could also just test everything with manual QA. Literally pay some humans to click through your application following a defined path and asserting outcomes. Every time you make a change. How to see if someone is arguing in bad faith? Well, they pretend that reductio ad absurdum is a valid argument > Obviously all of these have different costs. And obviously, testing a pure function with unit tests (whether example based or property based) is going to be cheaper than testing the behaviour of that same function while incidentally testing how it integrates with its collaborators. Let's see. A single scenario in an integration test: - tests multiple code paths removing the need for multiple unit tests along that code path - tests externally observable behaviour of the app/api/system is according to spec/docs - tests that all units (that would otherwise be tested in isolation from each other) actually work together This is obviously cheaper. Programmer (the expensive part) has to write less code, the system doesn't suddenly break because someone didn't wire units together (the insanely expensive part, 'cause everything was mocked in tests; unironically true story that hammered the final nail in the coffin of unit tests for me). By the way, here's what Kent Beck has to say about unit tests: https://stackoverflow.com/a/153565 https://stackoverflow.com/a/153565 --- start quote --- I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence --- end quote ---