langager

I really enjoyed this article and spoke to a lot of the lived experience I've had in over abstracted codebases that had tests incredibly coupled to implementation.

I think this title could maybe be rewritten as "Unit Testing that Requires Mocks is Overrated".

Unit testing something that has no (or very simple) dependencies is great. For example: - some kind of encryption that takes in a string as a key - serialization that expects the same output as the input passed in - a transform function that takes in one type and expects a different type out

As soon as you rely on a DB, file system, etc... you're probably better off with an e2e test.

At the end of the day, it comes down to data contracts. This could be the functions a package exposes or the GQL/REST/gRPC/whatever API. That is the most important thing to not break the behavior of. Write good tests that target the external facing data contracts and treat implementation like a black box and you'll be empowered to do the important things that tests should enable like refactoring, reworking abstractions that may have made sense at one point, but no longer do, and let your codebase evolve as you learn.

Tests that are a barrier to reworking internal abstractions are not good tests.

I've been getting paid to write JS/TS for about 10 years. I think I've used the `class` keyword less than 5 times in the last 5 years and feel better off without it. I've found that a more functional style leads to better separation of state/data from any logic you have to write, allowing for a better testing experience and an easier time refactoring. Plus it means I have to think way less about what `this` means.

At the end of the day, features of languages are just tools, and sometimes they fit the problem you're trying to solve. I think it's also important to decide what tools to use in the context of what experience you and your team already have.

Also, it's hard to have small .js files when you use classes, and I love small files. I think Go made a great design decision to allow functions on structs to be implemented in separate files.

Location: Boulder, Co

Remote: Yes (office in Boulder/Denver area is cool too)

Willing to relocate: Nope

Technologies: Typescript, Node.js, Go, GraphQL, gRPC, Postgres, Kafka, Redshift, Microservices

Résumé/CV: https://drive.google.com/file/d/1ZJEYQa_u4kkLAcD8O96HmDGUd22...

Email: [email protected]