Category: JavaScript

I’ve learned 4 things this past 6 months doing peer reviews on many teams’ code in a large Angular code base.

• Pure Functions are not an easy sell
• Avoiding Dependencies in code is not obvious
• Anti-Mock crowd unfortunately is more nuanced
• Acceptance Test Ops continue to be challenging

There are a few options, and strategies. We’ve listed from easiest to most thorough.

1. Use any, then ask for help.
2. Use unknown
3. Use a Record with a string key and whatever value, like Record<string, any>.
4. Use IDontKnowYet as an aliased type or interface.
5. For a multitude of types, use an anonymous Union, like string | number. If you still don’t know, use string | number | any since we’ll know any is the outlier.
6. Use a Pick or Partial of an existing type you may already have nearby.

A habit I made in JavaScript, and later TypeScript, was to have Promises never fail, and instead return a Result type. This ensured async code worked like sync code, and didn’t randomly break the application. If someone decided to use async/await syntax, they could forget a try/catch and be “ok”. I only use that syntax in unit tests where you’d want things to explode sooner.

I’ve attempted recently to apply the same style to RxJS, and sadly it’s not working out. The first problem is that has the same contract as AWS Lambda: You can either get a return value, or an Exception if something went wrong. This allows AWS to support just about any programming language because almost all return values, and almost all have ways of making exceptions, intentionally, but most not.

I dissect these 3 statements and hopefully give you insight as to where devs are coming from that say that, a different perspective on using tests to design, and what you can do if you hate updating tests.