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 6 days ago | parent | next [-]

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 6 days ago \| parent [-]
		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.

▲

troupo 6 days ago | parent | prev | next [-]

> 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 6 days ago | parent [-]

This is utter nonsense.

▲

troupo 6 days ago | parent [-]

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

▲

yakshaving_jgt 6 days ago | parent [-]

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 5 days ago | parent [-]

> 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

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

	▲	yakshaving_jgt 5 days ago \| parent [-]
		Feel free to try coming up with a single integrated test that tests all 16 paths through this parsing function. https://news.ycombinator.com/item?id=45081378 > By the way, here's what Kent Beck has to say about unit tests As I pointed out to you earlier, I've been doing TDD for a long time. I'm already plenty familiar with Kent Beck's writing. --- I'm not convinced that you actually know what you're talking about. You've contradicted yourself a number of times when responding to me and to others. You construct straw men to argue against (who said everything needs to mocked in unit tests?). You've said "very few people write parsers", which is utter nonsense — parsing, whether you realise it or not, is one of the most common things you'll do as a working programmer. You've insisted that unit tests don't actually test that something works. You've created this false dichotomy where one has to choose between either isolated tests or integrated tests. All I can say is good luck to you mate.

▲

6 days ago | parent | prev [-]

[deleted]