Skip to content

Document mixing real framework services with AutoMock (#49)#61

Merged
tillig merged 2 commits into
developfrom
feature/issue-49-framework-services-docs
Jun 29, 2026
Merged

Document mixing real framework services with AutoMock (#49)#61
tillig merged 2 commits into
developfrom
feature/issue-49-framework-services-docs

Conversation

@tillig

@tillig tillig commented Jun 29, 2026

Copy link
Copy Markdown
Member

Addresses #49.

Background

In #49, constructing an EF Core DbContext inside an AutoMock container that also had logging wired up threw a NullReferenceException deep inside Microsoft.Extensions.Logging.

Root cause (not a defect to "fix" in code)

AutoMock supplies a mock for any service it can't otherwise resolve, including the individual elements of an otherwise-empty collection dependency. So IEnumerable<ILoggerProvider> — which is legitimately empty in normal DI — instead gets a single mock element injected. That loose mock's CreateLogger returns null, and LoggerFactory then dereferences the null.

This single-element injection is intentional, long-standing behavior (it's what lets you test collection-style dependencies), and it's shared identically with the FakeItEasy integration. It is also non-recursive — it stops at the mock boundary and does not cascade into nested collections. So rather than change that behavior (a breaking change with real downsides), this documents the interaction and the workaround.

The test-ordering quirk in the original report is EF Core's static service-provider cache masking the problem when a "good" path runs first; it's outside our control.

Change

Adds <remarks> to the AutoMock class describing that adding real framework services into the container can yield null-returning mocks in framework-consumed collections, and how to avoid it (register the concrete services the framework consumes).

Related

Companion documentation PR with the detailed guidance: autofac/Documentation#185

AutoMock injects a mock for any service it can't resolve, including the
elements of an otherwise-empty collection dependency. A loose mock returns
null for un-setup members, which can make a consuming framework (such as EF
Core resolving logger providers) throw a NullReferenceException. Add remarks
to the AutoMock class describing this and the workaround.
@codecov

codecov Bot commented Jun 29, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.99%. Comparing base (595df74) to head (d4363f6).

Additional details and impacted files
@@           Coverage Diff            @@
##           develop      #61   +/-   ##
========================================
  Coverage    90.99%   90.99%           
========================================
  Files            3        3           
  Lines          111      111           
  Branches        21       21           
========================================
  Hits           101      101           
  Misses           6        6           
  Partials         4        4           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@tillig
tillig merged commit 7e2d9f3 into develop Jun 29, 2026
12 checks passed
@tillig
tillig deleted the feature/issue-49-framework-services-docs branch June 29, 2026 21:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant