4 ms·

Unit tests are a poor man's type system.

solraph 3y ago
Types are wonderful, and a good type system makes so many errors disappear / impossible, that I'd otherwise have to write tests to cover in a dynamic language. Types however, are not a substitute for unit tests. No type system is going to tell me if my income tax calculator covers all the edge cases.
- haspok 3y ago
  I would argue that your income tax calculator logic should probably not be unit tested, it sounds complicated enough to involve multiple classes / units of code. What you really want to test is business logic, not code logic.
  - pasc1878 3y ago
    So the unit test is a business case. All tests should be on business logic - code logic might not fit the business case at all and so that should be a fail.
  - solraph 3y ago
    I was using the example of income tax as an entirely theoretical example of where types won't save you in response to the GP. That said, I don't follow what you mean by "to test is business logic, not code logic." To me, that is a distinction without difference. An income tax calculator in a (sane) tax system is essentially a set of pure of functions or classes. This is a perfect place for a unit test. I might have additional unit tests for sub components of the hairy bits, but it's still unit tests all the way.
cjfd 3y ago
You need both. The type system is not going to catch if you do Rectangle(width, height) where you should have done Rectangle(height, width).
- haspok 3y ago
  Maybe _your_ type system doesn't do that. It is perfectly possible to introduce type aliases to differentiate between X and Y coordinates - though usually it is not worth the trouble. (Unless you are working on the firmware of a nuclear missile - in which case it probably is :))
- d-lisp 3y ago
  I personally have a lot of informations coming from my text editor (emacs) when writing code, and I only want to say that your example does the opposite of what you meant; because of the type system, typing Rectangle TAB would likely print Rectangle(width, height) automatically and inform you with "width, a 32 bit float; height, a 32 bit float". I fail to find a better example (complex functions of high arity with parameters from the same type ?).
rhdunn 3y ago
It depends on what language you are using and what things you are testing. If you use a language like Python, having tests that pass things that aren't the type you are expecting are useful. Likewise passing nulls to a nullable parameter, or different objects to an Object/Any type (or even a different implementation/type to a supertype parameter). Those tests are part of the unit test repertoire, but unit tests should cover both expected cases/behaviour and unexpected cases.

Types are wonderful, and a good type system makes so many errors disappear / impossible, that I'd otherwise have to write tests to cover in a dynamic language. Types however, are not a substitute for unit tests. No type system is going to tell me if my income tax calculator covers all the edge cases.

haspok 3y ago
I would argue that your income tax calculator logic should probably not be unit tested, it sounds complicated enough to involve multiple classes / units of code. What you really want to test is business logic, not code logic.
- pasc1878 3y ago
  So the unit test is a business case. All tests should be on business logic - code logic might not fit the business case at all and so that should be a fail.
- solraph 3y ago
  I was using the example of income tax as an entirely theoretical example of where types won't save you in response to the GP. That said, I don't follow what you mean by "to test is business logic, not code logic." To me, that is a distinction without difference. An income tax calculator in a (sane) tax system is essentially a set of pure of functions or classes. This is a perfect place for a unit test. I might have additional unit tests for sub components of the hairy bits, but it's still unit tests all the way.

cjfd 3y ago

You need both. The type system is not going to catch if you do Rectangle(width, height) where you should have done Rectangle(height, width).

haspok 3y ago
Maybe _your_ type system doesn't do that. It is perfectly possible to introduce type aliases to differentiate between X and Y coordinates - though usually it is not worth the trouble. (Unless you are working on the firmware of a nuclear missile - in which case it probably is :))
d-lisp 3y ago
I personally have a lot of informations coming from my text editor (emacs) when writing code, and I only want to say that your example does the opposite of what you meant; because of the type system, typing Rectangle TAB would likely print Rectangle(width, height) automatically and inform you with "width, a 32 bit float; height, a 32 bit float". I fail to find a better example (complex functions of high arity with parameters from the same type ?).

rhdunn 3y ago

It depends on what language you are using and what things you are testing. If you use a language like Python, having tests that pass things that aren't the type you are expecting are useful. Likewise passing nulls to a nullable parameter, or different objects to an Object/Any type (or even a different implementation/type to a supertype parameter). Those tests are part of the unit test repertoire, but unit tests should cover both expected cases/behaviour and unexpected cases.