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:

Can native web APIs replace custom components in 2025?

Learn how native web APIs such as dialog, details, and Popover bring accessibility, performance, and simplicity without custom components.

Daniel Schwarz
Sep 12, 2025 â‹… 9 min read
too many tools: How to manage frontend tool overload

Too many tools: How to manage frontend tool overload

Read about how the growth of frontend development created so many tools, and how to manage tool overload within your team.

Shalitha Suranga
Sep 11, 2025 â‹… 12 min read
shruti kapoor the modern ai stack

What you actually need to build and ship AI-powered apps in 2025

Discover what you actually need to build and ship AI-powered apps in 2025, with tips for which tools to choose and how to implement them.

Shruti Kapoor
Sep 10, 2025 â‹… 10 min read
ai dev tool power rankings

AI dev tool power rankings & comparison [Sept 2025]

Compare the top AI development tools and models of September 2025. View updated rankings, feature breakdowns, and find the best fit for you.

Chizaram Ken
Sep 10, 2025 â‹… 9 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