3 ms·

"relying only on typing will cover about 10% of the error types". It's not about the percentage of error types. Its about the percentage of errors. A very high

"relying only on typing will cover about 10% of the error types". It's not about the percentage of error types. Its about the percentage of errors. A very high percentage of unit tests in a dynamic language are written to catch type errors. That work is a waste of time when a type system could check it for you. The reason for this is that type errors are involved in all code. A FileExistsError only applies if I am working with files. (Plus with types you get the added benefit of inline documentation and better tooling.)

gaius 10y ago
It's also about the compiler guaranteeing to enumerate every code path in and out of every function. A human writing tests is limited by what they think will happen, but the compiler knows.
sametmax 10y ago
> A very high percentage of unit tests in a dynamic language are written to catch type errors. Absolutly not. If you do it you are doing it wrong. Check this out: https://github.com/Tygs/tygs/blob/master/tests/test_components.py https://github.com/Tygs/tygs/blob/master/tests/test_componen... The type checks are "isinstance". It's 10% of the checks, and most of the time I don't even have those, my colleague insisted. The rest are the most important tests: they test behavior, not types. Do not assert a dynamic language means testing types, it's just not true. Bad testers test types.
- the_af 10y ago
  "isInstance" doesn't cover the full range of type errors. It simply covers whether something is, say, an Int or a String. Types can encode much more. They can encode behavior.
zephyrfalcon 10y ago
> A very high percentage of unit tests in a dynamic language are written to catch type errors. I'm not sure where you got that information. You don't actually write tests to catch types. You write tests to check behavior. While it is possible that actual type errors come out of the woodwork while doing that, that is not the reason why the test was written in the first place; and after fixing such a type error, the test itself is still valid (again because it is making sure that the code exhibits the desired behavior). I don't think I have EVER written a test just to check for types (in Python). Neither do I pepper my code with 'assert isinstance(x, some_class)' because it just goes against the grain of a dynamically typed language.
- gaius 10y ago
  In strongly typed languages you embed constraints about your programs behavior in the type system.
  - zephyrfalcon 10y ago
    Really? What language allows you to encode business logic into its type system? I'm talking about things like, what happens if you press this button; is this calculation correct; does this lookup give me the desired results; does X get stored in the database correctly (or retrieved from it); etc. I don't know of any type system that lets you check these things. (Also, I assume s/strongly/statically; Python is a strongly typed language. Granted, not everybody agrees about the terminology...)
    - gaius 10y ago
      You're moving the goalposts now; those are integration not unit tests. But the type system certainly can validate/enforce that the column you select from the DB into an integer, really is an integer in the DB too. OCaml does this with Postgres. It can also make sure the end result of a calculation is of the correct dimensions, that you're not adding cms to inches, etc etc.
    - the_af 10y ago
      A lot can be said with types beyond simply checking things like "is this a String or an Int?". Depending on the power of your type checker, you can say (with varying degrees of convenience) things like "this integer will always be positive", "this is always going to be a non-empty list", "these two functions can be composed", "I've exhausted all possible values for this variable; I know it because the compiler told me so", "it is safe to call this function, and I know it won't touch the database or do any kind of I/O", and many more. Whenever you called a function and it wrote to a file when you didn't want that, that's also a type error!

gaius 10y ago

It's also about the compiler guaranteeing to enumerate every code path in and out of every function. A human writing tests is limited by what they think will happen, but the compiler knows.

sametmax 10y ago

> A very high percentage of unit tests in a dynamic language are written to catch type errors. Absolutly not. If you do it you are doing it wrong. Check this out: https://github.com/Tygs/tygs/blob/master/tests/test_components.py https://github.com/Tygs/tygs/blob/master/tests/test_componen... The type checks are "isinstance". It's 10% of the checks, and most of the time I don't even have those, my colleague insisted. The rest are the most important tests: they test behavior, not types. Do not assert a dynamic language means testing types, it's just not true. Bad testers test types.

the_af 10y ago
"isInstance" doesn't cover the full range of type errors. It simply covers whether something is, say, an Int or a String. Types can encode much more. They can encode behavior.

zephyrfalcon 10y ago

> A very high percentage of unit tests in a dynamic language are written to catch type errors. I'm not sure where you got that information. You don't actually write tests to catch types. You write tests to check behavior. While it is possible that actual type errors come out of the woodwork while doing that, that is not the reason why the test was written in the first place; and after fixing such a type error, the test itself is still valid (again because it is making sure that the code exhibits the desired behavior). I don't think I have EVER written a test just to check for types (in Python). Neither do I pepper my code with 'assert isinstance(x, some_class)' because it just goes against the grain of a dynamically typed language.

gaius 10y ago
In strongly typed languages you embed constraints about your programs behavior in the type system.
- zephyrfalcon 10y ago
  Really? What language allows you to encode business logic into its type system? I'm talking about things like, what happens if you press this button; is this calculation correct; does this lookup give me the desired results; does X get stored in the database correctly (or retrieved from it); etc. I don't know of any type system that lets you check these things. (Also, I assume s/strongly/statically; Python is a strongly typed language. Granted, not everybody agrees about the terminology...)
  - gaius 10y ago
    You're moving the goalposts now; those are integration not unit tests. But the type system certainly can validate/enforce that the column you select from the DB into an integer, really is an integer in the DB too. OCaml does this with Postgres. It can also make sure the end result of a calculation is of the correct dimensions, that you're not adding cms to inches, etc etc.
  - the_af 10y ago
    A lot can be said with types beyond simply checking things like "is this a String or an Int?". Depending on the power of your type checker, you can say (with varying degrees of convenience) things like "this integer will always be positive", "this is always going to be a non-empty list", "these two functions can be composed", "I've exhausted all possible values for this variable; I know it because the compiler told me so", "it is safe to call this function, and I know it won't touch the database or do any kind of I/O", and many more. Whenever you called a function and it wrote to a file when you didn't want that, that's also a type error!