4 ms·
The first thing I see when I look at this is "Where are the unit tests?" This is somewhere in the realm of "clever" or "efficient" code: it looks like it could
by gregmac 2y ago
The first thing I see when I look at this is "Where are the unit tests?"
This is somewhere in the realm of "clever" or "efficient" code: it looks like it could be written in an easier-to-grok way as dozens of lines of if statements, but I assume there is a reason it wasn't (that is better than "just because"). AI-generated or not, someone or team is responsible for making sure the code/app/service is working for customers, and they have to be able to fix bugs, maintain and modify this.
Does it work today? As a reviewer (or coming across this while fixing a bug), I only know by either trying it, or spending quite a long time to understand and analyze it in my head. Unit tests are the easiest way of "trying it", with all the edge cases and then some.
What if I'm faced with modifying this in 6 or 12 months? Even if I wrote it, chances are my internal mental model is gone. I'd like some reasonable assurance I am not breaking anything.
Also, I'd like to not be the only one responsible for this forever, so I want to let other people modify it. Unit tests are the guard rails that let me say "Go ahead and do whatever you'd like, but don't break the tests".
- rtpg 2y agoYou can scaffold up "unit tests", but honestly for type-level stuff you are working in a different space entirely. Your types are correctness proofs, so your underlying code is either typed correctly or not. There's not really a middle ground that unit tests catch. Having said that, typescript's soundness issues make it easy to drive a truck through a certain kind of issue, but generally speaking if your type-level programming is no good you're not really going to be able to run unit tests, let alone validate them. Your code just won't go anywhere.
- woooooo 2y agoYou can't test the function or endpoint from a business definition "does the right thing" perspective?
- eptcyka 2y agoYou cannot because if you're testing the type level wizardry, the failure case will not compile.
- woooooo 2y agoTest your functions and endpoints, nobody cares about the internal wizardry. That's an implementation detail. There's a reason you coded the endpoint, and often times the business logic required is inelegant, self-contradictory and stupid. That's what has to work.
- matsemann 2y agoMaybe not checked in, but I've made "tests" before where the code really doesn't assert things, but whether it compiles or not is what I'm after. It's far too easy in Typescript to do something where you actually lose your type safety without realizing. So I could for instance have some dummy code that calls foo.bar() but crashes in runtime, and my goal is to fix the typing throughout some generic functions so that it catches the mistake compile time.
- johnfn 2y agoThat's not really true; I see unit-tests for type-level stuff frequently. Here's some: https://github.com/RuyiLi/cursed-typescript/blob/master/type-challenges/compare-integers.ts#L49 https://github.com/RuyiLi/cursed-typescript/blob/master/type...
- tylersmith 2y agoThese tools can also generate tests, the OP just doesn't discuss it.
- hesviiggvv 2y agoType level unit tests are indeed super helpful, and in my experience they are easier to write than “real” unit tests, because mocking is trivial.