Repository navigation
Provide the ability to test directives that contain input signals without wrapper components #54164
Description
Which @angular/* package(s) are relevant/related to the feature request?
core
Description
Given the following simple directive with a signal input:
@Directive({
selector: '[appSimple]',
standalone: true,
host: {
'(click)': 'doSomething()',
}
})
export class SimpleDirective {
data = input.required<string>();
doSomething() {
console.log(this.data());
}
}There is no way for me to write a test because I can not create a "DirectiveFixture" where I can "setInput"
Proposed solution
Provide a similar approach as TestBed.compileComponents but for directives.
Alternatives considered
Stick with requiring wrapper components to test, but add documentation when input signals become available as part of the public API.
Activity
jamcoupe commentedon Feb 3, 2024
@topdev658 Your example is how I am currently testing signal directives.
This feature request was to not require wrapper component to test signal directives which is what your example does.
JeanMeche commentedon May 1, 2024
My take on this would be that, it doesn't really make sense to test a directive without a HostElement as it would not represent how they behave at runtime.
Depending on your test scenario, it could make sense to extract some logic from your directive into a separate class/function and test it separately.
snortblt commentedon Sep 18, 2024
Disagree for two reasons: 1) unit testing is all about isolation. If there are differences, those would necessarily be due to the host component, whose behavior we are trying to avoid testing in the first place. 2) Clearly the angular team disagrees because the boilerplate test generated for directives by
ng generate directiveuses no host component or even any fixture at all.JeanMeche commentedon Nov 26, 2024
The thing is that directive never live in isolation, they are always in the context of a host component.
If anything that is located inside the directive can live in isolation, then it should be as such and tested as such.
mfstapert-xip commentedon Jul 7, 2026
Don't disagree with @JeanMeche, but it's hard to argue that the ergonomics and documentation around testing directives is poor. Before signal inputs you were able to test directives in just their own test file without setting up test-specific components. Also docs don't have an canonical example on how to test the inputs of a directive so you have to stumble across this topic to get that confirmation.
If I expand this page with an example that includes testing an directive with inputs using a component local to the test will it be accepted?
JeanMeche commentedon Jul 7, 2026
Sure, this page could deserve some improvements.
mfstapert-xip commentedon Jul 21, 2026
I've opened a pull: #69878
I could have revised the page some more, but I'm not sure about the intent, this way at least there is an explicit example.
feat(core): add utility for testing directives
feat(core): add utility for testing directives
feat(core): add utility for testing directives