You 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.
Maybe 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.
Test 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.
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.