A: when changing a technical details break one or more tests (lets omit compiling errors linked to architecture changes).

For example:
- changing the ORM
- changing the implementation of an api gateway
- changing your encryption library
- refactoring your domain objects
- creating a domain service
- moving from Postgres to Mongo
- using a new IAM system
…

Unit tests, focused on behavior, are there for immediate feedback, for coding faster, to refactor without fear...
The only reason to break those tests suites should be : changements of the behaviour or the requirements.

When they slow you down better to code it differently or maybe focus on upper layer for testing your system e2e, which is naturally coupled to those technical details.