Remix clone Hacker News

They're also suggesting a method of testing which almost certainly doesn't offer sufficient assurance under most circumstances will uncover all possible bugs. When I've got concurrency in an application, I'll use unit tests here and there, but mostly I want assurance that the entire system behaves as expected. It's too much complexity to rely on unit tests.

▲

hnlmorg 4 days ago | parent | next [-]

Very true. As an author of a several multithreaded applications, I concur that unit testing thread interactions is hard and seldom exhaustive.

▲

latchkey 4 days ago | parent [-]

It is not exhaustive because you haven't taken the effort to do it. It isn't easy, you have to write you code in a way that can be tested. It takes planning and effort to do this, but it pays off with having applications that aren't full of bugs.

▲

macintux 4 days ago | parent | next [-]

You sound like the people who argue that, despite decades of security vulnerabilities offering evidence otherwise, C is perfectly safe if you know what you’re doing and just put more effort into it.

Technically you may be right, but it’s not a helpful viewpoint. What the world needs are abstractions that are easier to understand and program correctly, not assertions that everyone else is doing it wrong and just needs to be smarter/work harder.

▲

latchkey 4 days ago | parent [-]

That's absurd, I'm not arguing anything of the sort.

If you want an analogy, I'm arguing that a condom helps prevent STD's and unwanted pregnancies. It isn't perfect, but at least it is better than not wearing a condom at all. Nobody loves wearing a condom, but we do it cause it is the right thing to do.

▲

dymk 4 days ago | parent [-]

You can't prove away chlamydia or an unwanted pregnancy, but you can provably eliminate whole classes of logic errors by having more powerful type systems.

	▲	latchkey 4 days ago \| parent [-]
		100%. Compilers for the win for sure. It was a big reason why I started to write Java code and move away from PHP. This lead me to co-found Java @ Apache.

▲

hnlmorg 4 days ago | parent | prev [-]

It’s not exhaustive because complex multi-threaded software has a plethora of hidden edge cases, many of which actually fall outside the traditional remit of a unit test.

This is where other forms of software testing come into play. Such as integration tests.

▲

latchkey 4 days ago | parent [-]

wtf is a hidden edge case? Is that like flying a plane with blinders on? Come on...

You write tests to cover edge cases. If you miss one, you write more tests when you come across them. This isn't magic.

▲

hnlmorg 4 days ago | parent [-]

> If you miss one, you write more tests when you come across them.

…before such point you have hard to find bugs in your software.

And that’s the crux of everyone’s argument against your “just write better code” fallacy ;)

> This isn't magic.

No it’s not. That’s why people disagree with your assessment that unit tests can catch every type of bug.

If unit tests really were that magical then we wouldn’t need for other methods of tests.

I mean, do you even know what a unit test is? It’s meant to be self-contained but the problem with multithreaded code is that you can start to introduce side effects that happen outside that functions scope.

I’ve got exactly that issue right now calling OS APIs from cgo. Some of those APIs (particularly with SDL) are very thread sensitive and you cannot unit test for that because the problem lies outside that functions scope. So the only way to test for that is with e2e or integration tests instead.

▲

latchkey 4 days ago | parent [-]

I didn't say "just write better code", I said write more tests. Writing those tests will produce better code.

I also never said unit tests were the ONLY tests.

	▲	hnlmorg 3 days ago \| parent \| next [-]
		But you were ONLY talking about unit tests for catching concurrency bugs; bugs which often fall outside the scope of a unit being tested. Nobody disagrees with your point about the importance of unit tests. But the way you present that point is more than a little naive (and that’s the polite way of putting it).
	▲	lenkite 4 days ago \| parent \| prev [-]
		> If you write comprehensive unit tests...

▲

latchkey 4 days ago | parent | prev [-]

All this "complexity" can be unit tested, I've done it.

Trying to handwave and say that your code is too complex to be tested is very strange to me. Maybe take a step back and ask yourself why your code is too complicated to test. Maybe refactor it a bit to be less complicated or more easily testable.