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 Kimi K2 is a frontend game-changer

Agentic AI for 5x less: Why Kimi K2 is a frontend game-changer

Kimi K2 doesn’t just tell you what to write or how to solve a problem; it writes the code, executes the tasks, and gets stuff done.

Chizaram Ken
Aug 22, 2025 â‹… 8 min read
Gemini CLI vs Codex CLI: A Comparative Analysis

Does Gemini CLI fall short? Here’s how Codex compares

Compare Codex CLI vs Gemini CLI for real-world coding tasks. See strengths, weaknesses, and which AI CLI fits your developer workflow best.

Emmanuel John
Aug 20, 2025 â‹… 8 min read
Is Next.js Still Developer-Friendly?

Is Next.js still developer-friendly?

The question isn’t whether Next.js is good or bad; it’s whether the productivity gains are worth the complexity tax.

Chizaram Ken
Aug 20, 2025 â‹… 5 min read
Don’t Let AI Erase The Next Generation Of Dev Leaders

Don’t let AI erase the next generation of dev leaders

As AI tools take over more routine coding work, some companies are cutting early-career dev roles — a short-sighted move that could quietly erode the next generation of tech leaders if we aren’t careful.

Jack Herrington
Aug 19, 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