I enjoy tools that automate dependency updates in my projects (looking at you, Renovate and Dependabot). They save my team a lot of time: with a quick glance and the push of a couple buttons, I can update dozens of dependencies in a repository. Even better, the work came to me, I didn’t need to go looking for release schedules or subscribe to a newsletter. This is a big change to how I see teams handle 3rd party updates.

Merging an update just because the tests pass creates a mess.

# Context: What do these dependency automation tools do?

They help in the following ways:

• Notify project maintainers that a dependency has an update
• Modify the project’s package manifest to reference the updated code
• Open a Pull Request and highlight some context on the change
• and because you have CI set up, they trigger your automated tests

When I start my day and look at a Pull Request created by a tool like this, I may see a lot of encouraging green checkmarks✅ declaring merge-worthiness.

# The tools did all the work, I can review & merge, right?

Seeing green checkmarks is necessary but not sufficient to merge. I trust automated checks to tell me where to prioritize my review time. As the human in the loop, I should verify:

1. Did the automated tests pass?
2. Does the library have a history of causing trouble? Maybe I should manually test the change.
3. Does the package follow semantic versioning? Is their a compatibility break from a major update? What if the break doesn’t change the API specification, but critical details in the payload data?

With answers “Yes”, “No Problem”, and “No”, I could just merge…

The question “Did the automated tests pass?” becomes “Is there automated test coverage in my project and does it cover the use of this dependency? Did those tests pass?”

# Let’s see an example of untested dependencies slipping through

In this example, suppose a dependency called ThirdPartyAuth is an important part of the business logic. Below I’ll show some of the potential misunderstandings from different testing strategies.

// Important business logic that takes a callback/function parameter.
doGoodThings(maybeAMockedRequestFunction) {
  maybeAMockedRequestFunction()
}

RealRequest() {
  return http_request(
    'https://example.com',
    ThirdPartyAuth.coolLibraryAuthV2()
  )
}

doGoodThings(RealRequest)

# Test Example #1: No Test

Test success reported with no tests run. Do I remember during code review?

// A commented out test stub.
// Test_doGoodThings()

✔️ Success // No tests were run

# Test Example #2: Mocked Test

End-to-end testing can be expensive to write and much more expensive to maintain. Instead, we could mock the responses from external APIs and scope the tests to local business logic.

This test does not cover the use of the ThirdPartyAuth library.

MockRequest() {
  return "OK"
}

Test_doGoodThings(MockRequest)

✔️ Success // What does that mean?

# Test Example #3: End-to-End Test

The integration of ThirdPartyAuth.coolLibraryAuthV2() with the codebase is verified.

If the test fails it may be a breaking change in the library or perhaps https://example.com is down.

Test_doGoodThings(RealRequest)

✅ Success // Probability of false negative > false positive

The value of the ✅ passing test is limited by the depth of test coverage and my knowledge of the limitation. No only me: since my team handles maintenance on a rotating basis, the value of the tests depends on how well each teammate understands those limitations.

# Functionality not broken, but update not complete

Just because a library works doesn’t mean it is used effectively.

When a dependency has significant changes over time, it likely gains new methods, recommended usage patterns, and planned deprecations on old ways of working. Upgrading the dependency without understanding the new, happy paths sets up a future with a broken update.

Today’s outdated practice is tomorrow’s deprecated design.

# Call to Action

Passing tests can be deceptive, and package manifests aren’t the only spot in your codebase to need changes when a big update happens.

In terms of Renovate configuration, maybe add some extra guidance to those Pull Requests:

{
  "prBodyNotes": "Do the tests cover this dependency? You may have more work to do."
}