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:

Wasm 3 Before GTA 6 LogRocket Article

We got Wasm 3.0 before GTA 6: Meet the web’s new engine

Discover how WebAssembly 3.0’s garbage collector, exception handling, and Memory64 transform Wasm into a true mainstream web platform.

Ikeh Akinyemi
Oct 3, 2025 ⋅ 2 min read

How to use AI to build accurate ShadCN components

AI agents often break shadcn/ui components with outdated docs or made-up props. The MCP server fixes this by giving live access to registries. In this tutorial, we’ll set it up and build a Kanban board to show it in action.

Chizaram Ken
Oct 3, 2025 ⋅ 5 min read
Rust Project for Web Services LogRocket Article

The best way to structure Rust web services

Learn how to structure Rust web services with clean architecture, Cargo workspaces, and modular crates for scalable, maintainable backends.

Jude Miracle
Oct 2, 2025 ⋅ 2 min read
andrew evans headshot

A spec-first workflow for building with agentic AI

Andrew Evans gives his take on agentic AI and walks through a step-by-step method to build a spec-first workflow using Claude Code.

Andrew Evans
Oct 1, 2025 ⋅ 18 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