←back to thread

361 points mmphosis | 2 comments | | HN request time: 0.5s | source
Show context
henning ◴[] No.42167434[source]
No.

> Know when you're testing the framework's capability. If you are, don't do it

Except that many frameworks are full of confusing behavior that is easy to misuse. It's funny that the post mentions `useEffect()` because `useEffect()` is so easy to misuse. Writing integration tests that make sure your app does what it is supposed to is totally fine.

> If you don't know what an API should look like, write the tests first as it'll force you to think of the "customer" which in this case is you

This is pointless. It doesn't give you any information, you're just guessing at what the API should look like. You won't actually know until it's integrated into a working application. The idea that you can design in a vacuum like this is wishful thinking.

> Copy-paste is OK once. The second time you're introducing duplication (i.e., three copies), don't. You should have enough data points to create a good enough abstraction.

No you won't, and it will often be with code that is similar in some ways but differs in others. Since the kind of people who write this kind of vague bullshit advice disapprove of things like boolean function parameters and use shitty languages that don't have metaprogramming support, this leads to "abstractions" that create awkward, tight coupling where changing one little thing breaks a million stupid fucking unit tests.

> Testability is correlated with good design. Something not being easily testable hints that the design needs to be changed.

Testability is neither necessary nor sufficient for any particular quality attribute. Depending on the application being written, it can be counterproductive to write out full unit tests for everything.

As always with these stupid "software engineering" posts, there is zero data, zero evidence, zero definitions of terms up front, and zero of anything that is actually real. It's just personal preference, making it dogma.

replies(1): >>42167554 #
necovek ◴[] No.42167554[source]
I challenge you to write code that is "testable" (easy to cover with tests for all the important functionality), but which is generally badly designed and structured.

(FWIW, while naming is probably as important, I am not accepting bad naming as that is too easy)

replies(1): >>42171469 #
1. morbicer ◴[] No.42171469[source]
I present you Uncle Bob's own pretty horrible code: https://qntm.org/clean
replies(1): >>42171732 #
2. necovek ◴[] No.42171732[source]
Thanks: yeah, that's indeed pretty bad.

FWIW, I don't see any tests for this, nor it looks simple to test it, so I don't consider this "testable" code — it looks like this was made to make other code testable, yet it fails to be testable itself.

Also, naming is horrible as well (also noted in the article).