2022-11-03
1820
#typescript
Paul Cowan
139904
Nov 3, 2022 ⋅ 6 min read

Write fewer tests by creating better TypeScript types

Paul Cowan Contract software developer.

Recent posts:

Why is Zod so slow?

Zod’s flexibility comes at a cost. This article breaks down why Zod is slower than AOT-compiled validators like Typia, and how to fix it with a build-time optimization that brings production-grade performance.

Ikeh Akinyemi
Oct 16, 2025 ⋅ 5 min read
the replay oct 15 graphic

The Replay (10/15/25): AI’s accessibility problem, React 19.2, and more

Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the October 15th issue.

Matt MacCormack
Oct 15, 2025 ⋅ 34 sec read
AI has an accessibility problem: What devs can do about it

AI has an accessibility problem: What devs can do about it

Jemima Abu examines where AI falls short on accessibility and how we can best harness AI while still building products that everyone can use.

Jemima Abu
Oct 15, 2025 ⋅ 10 min read

Want to run your AI model locally? Here’s what you should know

Cloud AI made scaling easy, but local AI brings control, cost stability, and data privacy. Explore the hardware realities, tradeoffs, and strategies shaping this shift.

Clara Ekekenta
Oct 15, 2025 ⋅ 6 min read
View all posts

One Reply to "Write fewer tests by creating better TypeScript types"

  1. Nice article I find good typechecking very helpful. However, having more code does not always mean that you have to more problems.

    Shared code that is to tightly coupled creates huge issues with business domain changes and refactoring.

    A properly decoupled system using MVVM that has proper Domain Drive Design and isolated business flows will help prevent unintended sideeffects as business needs change.

    Which may result in small portions of repeated code.

    This is prefered because business logic may change in a business flow and should not be shared across an entire application.

    DRY does not overide Single Resposibility and the scope you choose for SRP is important and should not bleed into different business flows with out a concrete reason.

    In MVVM this occurs fairly often at the view layer and even in the view-model.

    Each of the model, view and view-model layers can be tested and developed independently which enable paralalyzed development, AB testing, and easy refactoring.

    Tight type checking actually makes it more challenging to refactor and this is the reason kotlin was born.
    Kotlins loose type checking enable faster refactoring and iteration by enabling you to gaurd code blocks and domains with typechecks.

Leave a Reply