I very vividly remember writing a test for a ~40 loc class of pure functions. I started out thinking the exercise was a waste of time. This class is simple, has no mutable state, and should have no reason to change. Why bother testing it?
By the time I was done writing the test I had found three major bugs in that 40 loc, and it was a major aha moment. Truly enlightening.
It took a couple years to be accepted.
I built a property based testing library for ActionScript 3 (a fun journey in itself, with full test case reduction).
I was testing my testing library, and tried one of the most basic tests:
For any object A
A == decode(encode(A))
The more significant one came from testing a UI library we'd built for TVs (so you has up, down, left, right as movement). We had in the spec that if you moved focus by pressing right, pressing left would take you back to the thing you were on before. The test looked something like
For an arbitrary series of API calls generating the UI:
For an arbitrary list of movements the user makes:
If the focus changes, pressing the opposite direction moves your focus back where you came from
The spec was inconsistent, but because we'd tested explicit examples it had never been spotted. I've been a convert since.
I've never implemented property tests in an existing project without finding some bug.
I don't recommend building your own property testing library unless you really want to, I highly recommend in python hypothesis: https://hypothesis.readthedocs.io/en/latest/
So that puts it at about 1 bug per 20 LoC
Some estimates are something as high as 75 bugs per 1,000 LoC but that many bugs don't make it out to customers because of QA / Developer actions. So yeah, right on the money.
Well, you are currently participating in a thread that discusses this very question so there's that... and such threads are regular on HN.
I meant just that. People discuss it. What you want to say is that you have a strong opinion about it, that's OK and still possible with open questions
I guess in this context I mean that the question of static vs. dynamic in unit testing turns out to not be that hard, but the questions like "what is a unit test" and "should we unit test at all" are much muddier. Because people are confused or argumentative about the latter, they tend to pull the former into discussions that don't really have much to do with static vs. dynamic.
("For free" in scare quotes because of course there are always tradeoffs between different programming languages.)
If the testing is insufficient, as in practice it often surely is, then static typing would seem to be more valuable.
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/E...
If testing is enough to ensure the software is reliable, does the extra benefit of static typing make it worth the cost? This could be quite a lot of testing! The more testing that is done, the fewer type bugs remain that static typing would have found.
The argument you want to make against this is that static typing would have benefit beyond just finding bugs. The argument you don't want to make is that static typing reduces the need for testing.
In practice, when you write those tests for where the type system is lacking, you end up also incidentally testing where there is type system coverage, so there likely isn't much for industry to talk about.
Not to mention peace of mind when you go and mess around with code you wrote 9 months ago - if you mess up or didn't think of a corner case, there's decent chance it'll get caught by existing tests.
Depends on the language and the business logic. Types are a way of specifying preconditions and postconditions; a more expressive type system lets you rule out more edge cases by making illegal states unrepresentable.
In particular, I'm pretty sure it's not possible to have the thread bug from the article in Rust's type system.
For instance in a method that absolutely requires a specific type of object as a return, setting up a sacrificial default value to have the compiler happy, and actually build the inners of the function from there would be a normal course of action. That lets us run the code as we build it. But at the end if you forgot a case, it will still be a bug, except instead of having a wrong return type you get a wrong value. Weither it's better or not is up for debate.
Is Servo non-trivial? I think yes.
You should probably clarify that it’s not possible for you to write non-trivial programs in Rust.
And that’s okay! No one comes into this world knowing how to do any thing, but we can all learn if we choose to.
If you have a particular sticking point, I’d be glad to give advice.
So you save a “ton of time” writing the code without “cognitive overhead of types”, then you spend 3x as long writing the tests
Not true. Even today the majority of security bugs are simple buffer overflows, for example. The subtle bugs are more memorable, but that doesn't mean they're actually more common.
> major bugs are "this combination of preconditions yield a business logic edge case that wasn't accounted for". Static typing doesn't really help more than dynamic typing in these cases.
It absolutely does, if you put a little bit of effort into actually using it. Represent your business logic invariants in the type system, then the compiler won't let you accidentally violate them.