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:

How to use Claude to build a web app

Learn how to build a weather app using Claude, from setting up infrastructure to creating a functional UI that displays city-based forecasts.

Andrew Evans
May 28, 2025 â‹… 8 min read
Enhancing LLMs With Function Calling And The OpenAI API

Enhancing LLMs with function calling and the OpenAI API

Implement a scheduling assistant using the OpenAI API and function calling, no Model Context Procedure (MCP) required.

Kapeel Kokane
May 28, 2025 â‹… 11 min read
6 CSS Frameworks Every Developer Should Use In 2025

Top 6 CSS frameworks every frontend developer should know in 2025

Tight deadline? Bloated CSS options? This guide breaks down six modern CSS frameworks, from Beer CSS to CodeStitch, that help you build fast, beautiful UIs in 2025.

Murat YĂĽksel
May 27, 2025 â‹… 10 min read
A crash course in Next.js middleware

A crash course in Next.js middleware

Learn the ins and outs of Next.js middleware, which allows you to perform actions before a request is completed and modify the response accordingly.

Temitope Oyedele
May 23, 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