Well, allright then have a great day
Results from such tests will guarantee nothing. Imagine using a distributed kv store for real.
As said your assertion guarantees nothing. Maybe you should say: when a function is impure you cannot trust it. Compile time with types as well as runtime with automated testing.
Likies not needed. I even don’t like it myself.
The code in my example is pure, no side effects there: it effectively could be code testing an Elixir map. The assertion guarantees exactly what it tests: that if you associate a key to a value and immediately after you get the value for that key, you get the value that you put in. My point is that you cannot enforce that with a type signature, hence types and tests are not substitutes.
Distribution has no impact on the argument. How would you assert the correctness of a distributed system with static typing?
So you are not mutating state. A key value store stores state or am I missing something.
Huh? I just stated you cannot assert correctness with tests/types.
store = put(store, key, value) and the type signature
put(Store<K, V>, K, V) => Store<K, V> make it clear that the function returns a modified store, it’s not mutating state. If you want, there is state, but it’s not mutable.
But the thing is, it really doesn’t matter. You can still test code with side effects, and you cannot write a type signature that asserts that said side effect is correct. Which again is not a point against static typing, it’s saying that types and tests are not substitutes.
Agreed. Relevant discussion by Gary Bernhardt explaining this in detail: https://www.destroyallsoftware.com/talks/ideology
My point is that a lot of automated tests are not relevant anymore with types. Research
by for example Nadia Polikarpova shows that even more automated testing can be made irrelevant:
Moreover a lot of unit testing is a waste BDD / TDD criticized
If you are arguing that not all tests are useful, and that it is therefore possible to “overtest” by writing low-value tests that actually create more friction than value, I definitely agree. I also agree that static typing can help to keep the cost of change low (e.g. by making refactoring easier).
Not all tests are good. Tests are code, so bad tests are a painful reality.
I also agree that TDD is not the only true way, and definitely should not be practiced as a cult. I find it helps me guiding the solution when the problem space is clear, but I find it hinders me when I need to explore the problem first. I don’t think that TDD automatically leads to better software, I think it’s merely one technique at our disposal to use when it helps.
About TDD a link that I did not post yet:
The post is by (that name should be enough to trigger interest in the whole post + the link to the academic paper, for some at least):
He had a talk explicitly appreciated here Greg Wilson - What We Actually Know About Software Development, and Why We Believe It's True
Interesting paper from Coplien, a couple of tantalizing points
This seems to be rapidly turning into a rehashing of Code inspections vs unit tests.
The following point applies to both this document and the last one: Anybody can put a bunch of text on the web. The existence of that PDF does not prove or debunk anything. It’s relatively long, and we’re all pretty busy. If you want us to read it, you should provide evidence that it is well regarded, or provide some kind of compelling summary. Otherwise it is unlikely to have the impact you wish.
Edited the other tekst also Giving up on dynamic languages for your convenience.
I understand your feeling about these interview but maybe the point is not about testing, typed language and all the tech things but about you would fit in the actual dev team, with its best practices and its codebase.
As an interviewer, you may be the smartest dev I’ve encountered, if through my question I feel that you won’t respect the best practice, that you have no flexibility regarding our test practices (and we know not all of them are right for the moment), etc. it will be a no-go.
I suspect that these tech questions was just about who you are. Dev needs to have tech skills, but we are also people…
@StefanHoutzager that comic, in this context, is unnecessarily making fun of people that hold a different opinion without providing any support for your argument.
If you need to resort to mocking people, your argument is not very solid. Also, it makes me much less willing to engage in a discussion, and I assume a lot of other people too. All at a loss of this forum.
I hate to involve myself but:
Ben Wilson’s post itself was not friendly, and he has (like you yourself!) put a like below a plain hostile reaction: Code inspections vs unit tests
Compared to that my small joke is nothing.
Moreover the value of technical arguments is separate from matters like a joke.
Best practices should be discussed, as I tried here (the first post) and as far as I deemed it possible with the real interviewer. If they are not negotiable / dogmatic, the company has a problem. And again these two who like your post…
Calling out inappropriate behavior, or warning about the discussion spiraling into something that does not do any service to this community (like @benwilson512 did above), might feel unpleasant to you, but it is vital in order to maintain this a friendly space for discussion. If you feel that some reply was against the forum code of conduct that we all agree to abide to when posting on this forum, you should report that.
I called out your comic strip because it is, in the context of this discussion, a form of mocking or name-calling, which is explicitly against the forum rules.
In any case, this whole discussion is derailing, and it is becoming unpleasant for participants and readers. We either can keep it civil and on topic, or we should stop it here.
You clearly have other ideas about friendliness and inappropriate behaviour. But let’s get over this and keep arguing about technical matters. It’s interesting.
Just neglecting posts is often the best way to prevent threads from derailing I find.
This topic has gotten quite heated and is not leading anywhere productive so I am closing it.