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:

Use TypeScript Instead Of Python For ETL Pipelines

Use TypeScript instead of Python for ETL pipelines

Build a TypeScript ETL pipeline that extracts, transforms, and loads data using Prisma, node-cron, and modern async/await practices.

Muhammed Ali
Apr 17, 2025 â‹… 6 min read
best react charts libraries

Best React chart libraries (2025 update): Features, performance & use cases

Looking for the best React charting library? Compare the latest options, from Recharts to MUI X Charts, and see which one fits your project best.

Hafsah Emekoma
Apr 16, 2025 â‹… 10 min read
TypeScript Is Going Go: Why It's The Pragmatic Choice

TypeScript is going Go: Why it’s the pragmatic choice

Explore why the TypeScript team is porting the compiler to Go in TypeScript 7. Learn how this shift impacts performance, tooling, and the future of the TypeScript ecosystem.

John Reilly
Apr 16, 2025 â‹… 9 min read
six RAG types you should know

6 retrieval augmented generation (RAG) techniques you should know

Explore six powerful RAG techniques to enhance LLMs with external data for smarter, real-time AI-driven web applications.

Rosario De Chiara
Apr 16, 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