One developer I debated with this on has a training course, and it looks quite thorough and good based on a 5 minute scan. That is also worrisome because in our debate he said “DI injection has nothing to do with testing” and “adding DI in just so it’s ‘easier’ to test is a terrible choice. DI doesn’t make testing easier. It makes testing systems that use DI easier, and that’s a big distinction.”

Given the amount of AI psychosis going around currently, I’ve been introspective to ensure it’s not “me” that’s confused. When they say “AI does all coding”, no it doesn’t. When they say “AI is worthless”, no, it can be helpful. I’ve used various models, tools, and practices to learn. I’m left with either I’m a rational centrist… or both of them are lying or crazy… wait, am I the one who is crazy?

For DI, I have no insecurities. The industry has been doing this for 40+ years, and for good reasons. Over half to do with testing, the rest with design despite design being the origins. It’s long and documented. To say it has nothing to do with testing, or is as bad choice is just wrong. To build a training course without using DI at this point is willful ignorance.

Introduction

There is some negative cultural stigma associated with DI because in early Java, there was a large exodus of developers to other languages. While Java development & industry use remains strong, so to does the stigma of “Java esque” connotations.

I hate when YouTube videos dive into history for 7 minutes instead “just tell me why DI is good/bad!”. DI is good, for both Object-Oriented Programming and Functional Programming. However, to understand why it’s so tainted, understanding the history explains why you get completely different reactions from from developers when it “seems so obvious to just use it”.

I get it, but you’ll need to have this context if you ever start “just coding, DI is a normal part of that” and you have a new co-worker or client who freaks out, or the reverse, you see they use no DI in their code, and their tests are… “interesting”. (That’s tact for “I need a new job, I can’t work with this code base”).

Java/.NET Egress

Many Java developers in the 2000’s fled to Ruby and Rails with it’s simplicity and basically one way to do things. A lot less code, a lot less configuration (hence the convention over configuration mantra they have).

Years later, many did the same to Node.js. Specifically, JavaScript on the server, not the client. While it may seem normal to lump JavaScript server-side developers with web developers, they are definitely two different communities and do not always agree.

Understand that many in this world WERE OOP devs at heart, they just disagreed with the approach Java took, and were heavily prejudiced against the complexity. Understand, too, the age differences. Some were from a C++ background from the 80’s and 90’s, and had similiar feelings. Others were much younger, but after a short stint in both languages, without all the experience, and context, many were quick to say “This seems much simpler than Java”. So you had a type of cargo culting happening as well to varying degree’s, but it was encouraged, sometimes unknowingly.

The same with Python and Django. What all 3 had in common was they still supported Object-Oriented Programming (OOP) paradigms, but without the low return on investment type ceremony in early Java, and all the configuration complexity. This meant getting up to speed, from a variety of skill levels, was much easier, but you could still pick and choose to bring what you knew. The same applied to early .NET/C# as well. Want to use the same class keyword, and a few OOP design patterns? Works about the same. What to build a lighter weight Inversion of Control framework? Much easier to do in dynamic languages.

These are the people who taught me.

Why DI?

DI was created in the 80’s to make configuring OOP code bases easier. Whether using a concrete class, or an interface, you could make your classes more flexible by injecting the class or interface instead of having the class build itself. Classes are often a black box; that’s the whole point of OOP, encapsulation & abstraction (I’m ignoring message passing because that is a depressing path).

Instead of a class instantiating it’s own logger:

class MyGame {
  constructor() {
    this.logger = new Logger()
  }

  movePlayer() {
    this.logger.info("Moved to new position.")
  }
}

You’d instead inject a logger instance in the class constructor:

class MyGameDI {
  constructor(logger) {
    this.logger = logger
  }

  movePlayer() {
    this.logger.info("Moved to new position.")
  }
}

This was often called “Inversion of Control”. Before, the class you created had control of what it created and when, but now, it’s done by classes higher up the class tree. The advantages were it was easier to swap out a new class that did something different (in-memory logger for profiling vs disk), or multiple implementations (decoding mp3, ogg, wav, etc files for an audio player).

Around the same time (in non-Java circles) there was a small rejection of inheritance being a good idea. It took awhile, but many in OOP felt composition, having classes inside of classes instead of extending a base class, was a better idea for easier to maintain code. DI helped make composition easier and throughout the late 90’s and early 2000’s, the “Composition Over Inheritance” phrase grew in popularity. The cargo culting here was less because all a developer had to do was create large inheritance hierarchies, then maintain the mess they created. So the general idea that classes should not create their dependencies, but instead receive them from the outside became a lot more standardized (but still not widely accepted).

Years later it was also discovered this made testing a whole lot easier because the tests could inject fake versions and the real code could inject the real versions, but your main source code didn’t need to change. This really helped software quality and speed, while still retaining the design & architecture benefits.

Testing

During the 90’s, developers from many backgrounds started recognizing DI’s usefulness in testing. At the same time, a ground swell was happening in both how you test, and how you build software. Kent Beck’s XP book, which talked about Test Driven Development, came out in 1999, and then 2 years later in 2001, the Agile Manifesto came out. A year later, the Spring Framework for Java came out, utilizing the “DI Container”.

Despite the $500,000,000 Sun marketing budget for Java and OOP, there was also this growing sense of software craftsmanship culture growing. 3 years later in 2004, Martin Fowler wrote the seminal “Inversion of Control Containers and the Dependency Injection pattern” that further popularized and cemented DI as the term.

From then on, you had this perception that DI was strictly for testing, and had nothing to do with design despite DI’s original purpose being for design.

Containers

What never finalized was “who creates the dependencies” in production code. In tests it was straightforward; the test. However, with the advent of Spring, DI Containers, e.g. “things to make the dependencies” became the norm in multiple languages, namely Java, .NET, and even in niche communities like ActionScript in Flash. These started as a class with no state; just 2 static methods that “make the production dependencies” and “make the test dependencies”. They weren’t all bad; having a global way to inject different behaviors was powerful, no doubt, but they never stayed simple.

The myriad of type systems, and their continued low value also complicated approaches. Some used interfaces “because that’s what the Java OOP people do”, whereas in the dynamic languages, you didn’t need any of that.

The complexity just spread from there, eventually infecting the tests. Around the same time, JUnit and other frameworks inadvertently created confusion around which test-double to use, when. To this day, even with Gerard Meszaros’s definitions, no one can agree on what they mean.

The Python, Ruby, JavaScript, and other communities rejected wholesale any type of DI Containers, but oddly imported the test-double confusion.

They keep trying to make a comeback in various languages with various success and failures. .NET continues to have many projects happily using DI containers, whereas in Node.js NestJS (Nest, not Next)does have some traction, but goes against the core, original Node.js rejection of overly complicated Java DI setups and design pattern soup.

Functional Programming and DI

In the background, Functional Programming was still practiced in niches and dark shadows. Many intelligent programmers visited, and some of those came back with good ideas, most of the smarter ones not explaining where they got them to ensure better adoption.

Two particular things that helped popularize DI in the FP world was:

1. some FP languages had side-effects
2. the type systems removed the need for interfaces

And, a 1b, those practicing FP ideas in non-FP languages also had to deal with side-effects.

If you’re not an FP developer, I cannot underscore how much FP developers detest side-effects and spend every waking moment attempting to avoid side-effects. This is because the draw to FP is determinism. If you base all your code on math, and math is always right, and always wrong, then you feel super comfortable and excited to build an entire program out of it… because your program will be predictable.

Except, that’s not how the real world works; at a minimum, you have side-effects, things that aren’t deterministic like reading a file, connecting to a server, or accessing environment variables. Will they work? Who knows.

Since everything in functional programming (Scala/OCAML being weird) is usually functions, that means dependencies are passed in as parameters, just like you’d do it in class constructors.

function movePlayer(logger) { ... }

There is one thing you can do, though, even in non-FP languages, and that’s build pure functions that always work, or always fail. That means, using stubs, you can use DI to inject happy path stubs and unhappy path stubs for testing, just like you’d do in OOP.

stubInfo = (...rest) => {}
stubLogger = { info: stubInfo }
result = movePlayer(stubLogger)

That’s the reason you never see “DI Containers” in FP languages because why would you build a framework around passing a parameter to a function?

The last part is types. Type systems traditionally have been much better in FP languages. This means creating those stubs in FP tests is easier because the function has to match a type. Interfaces in classes typically start with 1 method, but never stay that way because it’s too easy to add more, which is why it gets harder and harder to create test-doubles for things in older OOP projects. In FP, a function type is 1 function type; that’s it. You can easily create a function that returns a particular value in a test. The types ensure they match; no need for interfaces, importing those interfaces, then creating a fake class to implement that interface. This varies between languages; some are easier, but less type safe, and some are more type safe, but harder to stub.

Either way, while one could say DI exists naturally FP, it’s quite the opposite; passing parameters to functions has been normal since functions and methods were created. OOP became so complicated, they had to invent Inversion of Control, then rebrand to Dependency Injection, cut their teeth on the mostly bad parts of DI containers, then learn that “huh, you know, instead of Constructor Injection, you could just pass the dependencies in on the method that needs it, we could call it Parameter Injection, like… passing a parameter to a function”.

Conclusions

DI has a 40+ year history from starting as a code design tool to eventually becoming a core testing tool for both OOP and FP languages over 20 years ago. It is a powerful design tool, and powerful testing tool, and it’s normal, and expected to use it. If someone says it shouldn’t be used for testing, they don’t know what they’re talking about.

Our types currently:

type RegionsPossibly = Array<any>
regions1 = [ 'us-east-1', 'us-west-2', null ]

The regions Array is actually a union of string or null, so:

type RegionsMaybe = Array<string | null>

That means you’d have to filter them out at runtime.

Kibosh that nonsense, let’s have an Array of strings only:

type Regions = Array<string>
regions3 = [ 'us-east-1', 'us-moo-cow-moo' ]

Oh no, that removed the null’s/undefined’s, but now we have the possibly a region isn’t really a region.

… what _is_ a Region?

Let’s define a region using a Union to narrow it to just 2:

type Region = 'us-east-1' | 'us-west-2'
type RegionsForRealDoh = Array<Region>

We’re good now, right?

regions4 = [ 'us-east-1', 'us-west-2', 'us-east-1' ]

Oh no… Array’s allow duplicates!

Tuple’s are fixed length Array’s and fixed position. Let’s define all possible combo’s:

type RegionsAndOnlyOne =
  | ['us-east-1', 'us-west-2']
  | ['us-west-2', 'us-east-1']

Nice! This compiles:

regions5 = ['us-east-1', 'us-west-2']

But if you added dupes, it wouldn’t.

“Hey, can you add ‘eu-west-2’?”

Dude… tuples are cool, but also exponential based on their amount. That’s a type with >9 possible combo’s, I’m not writing all that! What if there were a way to create a type from a Union that handled that in case you need to add a new one later?

type Permutations<T, U = T> =
  [T] extends [never]
    ? []
    : T extends T
      ? [T, ...Permutations<Exclude<U, T>>]
      : never

Think of Permutations like a function, but for types.

We can use that to create a more flexible way to creating fixed tuples for drawing lists in our UI code without having to manually type all permutations. As the list grows, the type will become quite unreadable too.

Let’s add our new region to our Union:

type RegionNew = 'us-east-1' | 'us-west-2' | 'eu-west-2'

Then create a type using our type function vs. manually typing all the possible tuples:

type RegionsWithEU = Permutations<RegionNew>

regions6:RegionsWithEU = [
  'us-east-1',
  'us-west-2',
  'eu-west-2'
]

That allows any order with no duplicates. It’s safe to use in your naive React/Angular/Vue code to iterate through a list and draw it, no Cypress/Playwright or Unit Tests needed to validate.

Much more preferable, and flexible compared to the 2nd attached image .

And with that, your NULL/undefined issue in your UI is crushed, no unit tests or acceptance tests needed. (That said, you should still write tests).

Happy (and safe) array dot map ‘ing!

1959: COBOL was called “Common Business Language” so non-programmers can read it. We were so expensive, the Pentagon got involved. Now COBOL Cowboys charge up to $1,000 per hour. The syntax morphed to OOP to be more likeable/usable by programmers.

197?: MYCIN, the 1st AI/LLM like inference engine, used to recommend antibiotics for infections. Despite high scores, wasn’t used because of hardware limitations (like the data center bulid out & RAM shortage drama we have today). Later Intellicorps LiveModel allowed you to leverage this AI to model business processes. This in turn spawned many data scientist & software consulting opportunities.

1973: Wang 2200 computer was called “computing calculator” so it wouldn’t scare customers. Marketed as “exceptionally easy to operate” and “no esoteric skills are required”. Yet saving files was so obtuse, many users would reach out to tech support (reminds me if iPhone file saving). You had to program it in BASIC vs. “File > Save As or Command + Shift + F”.

1982: OpenEdge Advanced Business Language: programming language w/integrated database build for people who weren’t computer scientists. Same later “I guess only programmers use this, let’s make it more OOP”.

1983: IBM’s Query Management Facility & Crystal Reports ensured business people could get reports without IT involvement. Some of my early consulting work was “customizing these charts for this data with these systems”.

1985: Went the other way, attempting to remove the Domain Expert via CLIPS (NASA’s AI Language). Some used these Expert Systems to generate code which sometimes was better than a dev could write. You don’t hear much about expert systems from the 90’s – 2000’s, but you DO hear about devs building rules engines leveraging those Domain Expert’s and their knowledge.

1991: Visual Basic, PowerBuilder, and Delphi lead the way in “using visuals, you don’t have to know much about code and databases”. Then those apps reached a level of complexity, consultants/freelancer devs were hired to fix, modify, or rewrite these apps.

1994: Many CASE tools like Rational Rose utilized visual boxes and arrows to represent domain models, such as UML, and these would generate your application, not needing developers. UML’s creators today use UML to communicate architecture to other devs, but doesn’t use it to generate the code.

2000’s: Business Rules Engines were touted to allow Business Analysts to make decisions without programmers (offering a loan, credit card, or mortgage). Many data specifications, tools, libraries, and microservices are created to allow access to these rules, and today many devs & data scientists build these systems to run businesses.

Excel: … yes, the business doesn’t need us here. All hail the almighty Excel.

With the exception of Excel, all of these innovations created to replace devs either led to more of us needed or new job roles created. All lead to new tools and approaches. COBOL to using English vs math in coding syntax, MYCIN for LISP & Prolog to be cool, inference engines to be a thing, including Bayesian networks, RAG, logic programming, and truth engines.

Wang + others lead to the personal computer market, word processors, & accessible accounting tools to run businesses & people’s lives. PC’s were gateway drugs for many people to be exposed to BASIC, VB, and game dev. The UI & case tools of the 90’s raised the bar on expectations of developers for IDE’s; we expect IDE’s nowadays to visually help us navigate our code intelligently and allow the LLMS to help.

The RAD Tooling was overshadowed by the RAD development style which helped influence the world away from Waterfall to more Agile styles of working. This allows us to continually learn with our users to help inform how to build things, leading to constant learning and fun. UML and it’s ilk has lead to all kinds of great data formats like JSON, Markdown, and Mermaid charts.

All of these are cool, new things we can learn to make our jobs better, or new types of jobs with software. They always try to replace us. We always end up with new toys instead.

So don’t worry about your software job being replaced, or no new junior positions. If you like being here because you have a short attention span, love to learn new things, and build stuff… or all 3, you’ve chosen a technically great time to get into software dev.

We’re all still figuring this AI thing out, which is fun! Part of software dev is bravely/excitedly wading head first into ambiguity and going “I wonder how this works… what does that button do…” While opportunities right now suck because of the economy & over hiring, there ARE a lot of people who really don’t want to be here who are leaving, and the economy historically always gets better. Just keep going.

Get that STEM degree, go to that bootcamp, or keep trying to break into your junior role; the amount of software we have to build is only increasing, and we’ll use AI/LLM’s to help us do it. Find your passion in the field, whether that’s web dev like me, game dev, systems programming, data science/machine learning, cyber… or maybe you just gravitate towards a particular language, that’s cool too. There are so many fun niches in software dev.

There seems to be this trend that light, cheap bikes may have adjustable preload. Mid-weight have some combo of adjustable preload, front & rear with much better suspension parts. Heavyweights max out on top brands.

This creates 4 markets:

• oil viscosity
• drop-in cartridges ( aka emulators)
• fork kits
• adjustable rear kits

Most of the cheap suspension has little holes in the tubes in the front; liquid goes through these little holes to absorb bumps. It’s called “damper rod fork”.

The rate at which that happens is based on how thick the fork oil is. They can get hydro-locked when the hole is too small or the oil the wrong viscosity; meaning the oil can’t move fast enough to allow the fork to absorb the bump. Tradeoff of cheap forks. Regardless of suspension, oil viscosity can help / hinder based on road vs dirt.

The cheap way to significantly improve your front forks is to use a drop-in cartridge (aka “fork emulators”). Little circles w/valves that go into your front fork and can be adjusted to let more oil in & out. Help prevent hydro-locking & can increase plush feeling.

Many fork kits also come with new springs you drop into the front forks. Some even come with a new tube where you drill your own hole in the metal. They range from $200 – $400, so a great low-hanging fruit. Emulators + kits can absorb bumps, remove brake dive, & help in turns.

Finally, rear shock kits vary, but many provide preload, rebound, and damping adjustment with JUST a turn click; no tools needed. You can work on the shock, refill the oil reservoir, and they can last a long time. Spring choice here can be customized to your weight as well.

A lot of the above depends on the bike, and what kind of riding they’re doing, and where. Me, the street is fine, it’s when I get my ADV bike on off road I notice it’s not great (at least when compared to the dual sports blasting past me). Worse when I’m plowing over rocks.

So it appears the lowest hanging fruit is, in order:

1. adjust your suspension; most suspensions, even preload, can drastically improve the enjoyment of your riding. Use what you have, no need to buy anything.
2. doing cartridge drop ins
3. upgrade rear

The rear seems to be least passionate since, off road in the dirt/rocks at least, the front are what contribute the most. Seems opposite for the sport bikes? Anyway, Ari Henning has a good video on how to do the cartridges yourself.

However, there appears to also be drop in from Cogent which does not drilling anything so much easier to install. I may do some more research to compare the drilling vs not.

I may seem odd buying a bike, then spending $300 – $3000 on upgrading the suspension. However, regardless of bike and riding style, this seems to be the consistent thing that links them all: everyone loves better suspension. That means even if your bike comes with “ok” suspension, EVERYONE seems to be in agreement if you have the money, it’s always worth it.

The common refrain is “Once you’ve experienced good suspension, you never go back”. Again, the repeated caution is “your existing suspension _may_ actually be great, you just didn’t adjust to your weight & riding style”; even just preload adjustment can help.

That said, $300 seems paltry to improve quality of life + the learning experience, so… I may give it a go.

I was inspired to write this because we’re dealing with testing Observability at work, and this article from Pete Hodgson describing the architecture and testing of Observability code in your Domain logic, that is quite good. I noticed the lack of types as a tool to help here, so wanted to add a simple technique that can help make testing easier.

Why Care

First, let’s cover why spies should be avoided, what they are if you’re not aware, and what side-effects are so you understand the problem we’re solving here.

Spies in unit tests should be avoided, and side-effects should at be tested with both types and Acceptance Tests, giving you confidence your code works as intended. This is nuanced depending upon programming language, but with TypeScript, we’re at a point where the types are good enough you don’t need to use spyies anymore in unit tests for the side-effects and can use types instead.

What’s Wrong With Spies?

Spies break encapsulation by knowing how your code works. This can discourage refactoring because even if you don’t change behavior of the code, it could break the tests. This in turn creates both the inability to easily refactor code and also creates a negative perception of the unit tests (e.g. tests break even though your code still works). You also have more state to remember in your unit test suite (e.g. beforeEach/afterEach). Finally, it increases the amount of code needed to code, read, and maintain in the unit tests.

My background is in Functional Programming with good type systems; there, everything returns a value, and you can use this typed value as part of the function signature to ensure “it’s doing the side-effects it needs to be”.

Why Even Use a Spy?

When writing tests, we often have side-effects in those tests that are important. If everything was just a pure function, our program wouldn’t actually do anything beyond warm a CPU; side-effects are what do important things in the real world. However, they often don’t return any value; the effect itself can happen outside of your program (e.g. logging to standard out, making a database update, etc).

It’s also common in Object Oriented Programming to encapsulate those effects as part of your abstraction. When these best practices were being created, good type systems weren’t in those languages, so types didn’t play a part in “design”; testing and architecture patterns did. Therefore many class methods will do mutation and other side-effects, and return nothing or void. You’ll continue to see that in both older blog posts/books & new, including many LLM’s.

Thus most testing literature will encourage, like us, that testing these side-effects is extremely important. How do they that is typically with what Gerard Meszaros calls “Spies”. After the code under test runs, you can then ask this spy “Were you called with the data we expect?”. This gives you confidence the code did it in fact call the side-effect full code in a way you expect.

Moving From Spies to Types

Let’s first show how a unit test is currently using a spy. Then we’ll move it towards using types.

From Spy

This code does some business logic and logs the result for Observability reasons (e.g. alerts in Honeycomb or Splunk or New Relic) with associated unit test that uses a spy.

function itsTheBusiness():BusinessResult {
  const result = doTheBusiness()
  console.log({ message: "business", result })
  return result
}

There are 2 unit tests; 1 validates the result that itsTheBusiness returns. We’re interested in the 2nd test; the one that validates console.log sent our message to ensure our Observability, e.g. our alerts in Honeycomb, continue to work.

it('should send the business result to logs', () => {
  const consoleSpy = vi.spyOn(console, 'log')
  const result = itsTheBusiness()
  expect(result).toBe('cow')
  expect(consoleSpy).toHaveBeenCalled()
});

This spy is required to be setup to test the code, and it “knows” a console is used, and that it uses the log method. If we comment out the console.log, the test fails, ensuring we log the result.

To Types

The type signature says that this function returns a BusinessResult, but it’s also doing some logging, so isn’t telling teh whole store of what this function does through the type signature. Currently, console.log doesn’t return anything useful; undefined doesn’t tell us it worked or what the data was.

We’ll assume console.log is a safe side-effect; meaning it always works, but is a side-effect. Examples include Math.random() and new Date(); non-deterministic, but won’t crash your program like fetch or fs.readFileSync. The difference is unlike console.log, both of those have return values.

Let’s create a light wrapper to fix that.

First, a type:

type LogMessage = { logMessage: any }

And second, a lightweight wrapper:

function log(logMessage:any):LogMessage {
  return { logMessage }
}

Now that our logger has the ability to return a useful return type, we can leverage that type by updating the itsTheBusiness function contract: You must return a BusinessResult AND a LogMessage.

// this...
function itsTheBusiness():BusinessResult

// ... to this
function itsTheBusiness():[BusinessResult, LogMessage]

Why is that subtle change important? Ask yourself “Where do I get a `LogMessage1?”

You get it from calling log. If you don’t call log, then you don’t have a LogMessage. If you don’t have a LogMessage, you can’t compile . This ensures compiling means your code is working as expected; the types help enforce that.

Let’s see what that looks like in practice. We’ll change our code to fulfill that new type signature:

function itsTheBusiness(): [BusinessResult, LogMessage] {
  const result = doTheBusiness();
  const logMessage = log({ message: 'business', result });
  return [result, logMessage]
}

The test still passes… ok, not much interesting there, just more to read. Watch what happens when we comment out the log call:

You see the compiler won’t let you compile; you need a LogMessage and the only way to get it is to call log.

Finally, let’s clean up the unit test by removing the spy:

it('should send the business result to logs', () => {
  const [ result ] = itsTheBusiness()
  expect(result).toBe('cow')
});

No more spy, but still ensures you’re logging is happening.

Conclusions

Spies are a way to assert methods/functions are being invoked in ways you expect. They are useful in programming styles where you have side-effects and want to assert those interactions are happening as you expect. Vitest improves this by making them type-safe.

However, they also have too many negative tradeoffs: they know how the code works, what dependencies they are using, and how those dependencies are used. This requires you to setup those spies and tear down those spies in unit tests. This is more state to manage in unit tests, more code to write, read, and maintain. This also creates a negative incentive not to refactor your code because you may break the tests despite the code itself not breaking.

We should continue to use Acceptance Tests to validate our side-effects happen the way we expect. However, types can also help shift the problem left, and add the “when it compiles, it works” mantra to add a level of confidence our code does in fact work along with the Acceptance Tests. This leverages both types and tests to move towards fearless releases.

We’ve used a type for a log message, but this can apply to any side-effect you deem important, and start notice you start reaching for a spy. Instead, you can model those effects as types, and ensure they’re used the way the side-effect should. There are many other benefits of this approach we didn’t cover, having side-effect types as values. Hopefully this gives you a taste of their benefits.