11 ms·
I'll say that any unit test for a bug which would have been caught by a more sophisticated type system is a waste. I don't know how much time people spend writi
by chongli 7y ago
I'll say that any unit test for a bug which would have been caught by a more sophisticated type system is a waste. I don't know how much time people spend writing such "obsolete tests", but I doubt it's insubstantial.
- ben0x539 7y agoIs it a waste to keep the test around until you're ready to switch to a more sophisticated type system?
- pojzon 7y agoA question, coz Im not sure I follow. How is type system (as described by wiki) supposed to test domain or functionality? Or are you talking here about completely different type system ?
- ben0x539 7y agoWhat you can do with the type system depends on the language. It can't replace tests entirely, but it can usually make some more boring tests superfluous, and in more exotic languages the type system can be surprisingly helpful.
- chongli 7y agoIt adds to the technical debt of the project. Some teams may never decide they're "ready" for a more sophisticated type system. That's fine, but they're still on the hook for maintaining those test suites which might pose significant roadblocks to refactoring or rewriting parts of the system.
- iso-8859-1 7y agoYou can prove a merge sort correct with dependent types. However, a typed implementation of merge sort will arguably be more difficult to mold into a TimSort if it isn't dependently typed. What you say?
- chongli 7y agoI don't have any experience with dependently typed languages. I hope (schedule permitting) to take a course in dependently typed programming (using Agda) and formal verification in the fall. I'll have much more to say on the topic after completing the course.
- baddox 7y agoPresumably you’d need to also know that the unit tests aren’t being used locally while developers develop. It’s pretty common to run a unit test watcher while doing local development, and have that catch breakages that never make it to CI.
- acjohnson55 7y agoWhat if most type system security is a waste? I don't personally believe this is the case, but I also can't tell you I know it to be false. What I do know is that types have a non-zero cost, and I think sometimes that's ignored, and only their benefits are acknowledged. But the efforts to bring types to historically dynamic languages show that not all common dynamic language idioms are amenable to reasonable type signatures. While some idioms (e.g. monkey patching) are problematic, that's not the case of all of them.
- walshemj 7y agoApart from a bit more typeing up front I cant see many costs to typing.
- osrec 7y agoThey can also be more difficult to refactor and adjust at a later date. This can be especially problematic if you're in an environment where logic needs to be altered rapidly in response to changing external conditions/requirements.
- dahfizz 7y agoThe added "difficulty" is just the cost of doing a proper, correct refactor. Dynamic languages are not helpful just because they let you write bugs faster.
- chrisan 7y agoI wouldnt even call that difficulty. That is a bloody loved feature in my book
- sjy 7y agoDevelopers are expensive though. If dynamic languages let you write buggy code in half the time that it would take to write perfect code in a static language, that would be an acceptable trade-off in many contexts.
- quanticle 7y agoThe problem is that sophisticated type systems only catch a subset of the bugs that a unit test can catch. For example, let's say I'm adding the ability to transfer funds from one account to the other in a banking application. I want to display a warning when the amount of money being transferred is over a certain percentage (let's say 95%) of the funds in the account. That's pretty easy to do in a unit test: create mock account, call the transferFunds() method, and verify that the warning is triggered when the value being transferred is over 95% of the amount in the account. How would I do that with a type system?
- maccard 7y agoI think the point is that if that was written in JS you would have a test to ensure your method behaves correctly with characters passed in, or strings, or just nil(/nul?) Whereas in Java et Al, you don't need any of those tests, you just make your parameter some sort of numeric and that just isn't a problem any more.
- xorcist 7y agoAt the risk of veering off topic, I'm genuinely curious what kind of bug that unit test is designed to catch? Given that transferFunds shows a warning over that 95% threshold, what type of change is going to break that logic? Some sort of botched code rewrite where values doesn't retain their meanings? That batchMode shouldn't trigger the warning? That race condition between the check and the actual transfer? Most of the unit testing I see is more like test-of-defintions (is fullName still 80 characters wide and doesn't accept null bytes?) which confuses me because a definition can only be correct or incorrect in context. I accept the usefulness in dynamic languages in the absence of types. My Personal preference is for tests to be a bit higher level (does login with a username containing null still cause an exception?) but I have come to terms with the fact that few people agree with me across multiple organizations, so there must be some point to this trivial testing that is completely lost on me.
- will4274 7y ago> Some sort of botched code rewrite where values doesn't retain their meanings? Yes, exactly. It's supposed to catch the rewrite where somebody turns (a * 100) / b > 95 into (a / b) * 100 > 95 and suddenly, the code doesn't work anymore. Showing a warning is full scenario - it has a whole UX. If this warning is important enough to have a PM, a UX designer, and be translated into 20 languages, it's important enough for the engineer to make sure it actually shows up when its supposed to.