Selfelected

Error message “Can’t bind to ‘ngIf’ since it isn’t a known property of ‘div'” solved

When testing a component in Angular you might receive the follwoting warning:

Can’t bind to ‘ngIf’ since it isn’t a known property of ‘div’

It might depend on you not declaring the component-under-test.

See this repo.

describe('AppComponent', () => {
   beforeEach(async () => {
     await TestBed.configureTestingModule({
       imports: [
         RouterTestingModule
       ],
       declarations: [
         AppComponent
       ],
     }).compileComponents();
   });
   it('should create the app', () => {
       const fixture = TestBed.createComponent(AppComponent);
       const app = fixture.componentInstance;
       expect(app).toBeTruthy();
     });
 });

The code is slightly different than the boiler plate Angular/Jasmine test code but still visualises the issue.

The row

const fixture = TestBed.createComponent(AppComponent);

Creates a component that must be declared in

declarations: [
  AppComponent
],

It took me an hour to find it due to code being convoluted.
If it saves you 5 minutes, it was worth writing this post.

Tip: fail explicitly during developing a test

When figuring out how to write a test – add an assert that always fails in the bottom. Remove it when you know the test works as it should.

Why: Because you might get interrupted to spend energy on something else. When you get back the test shines red and you know where to continue. No risk of sending sub par test code to a PR.

When you are testing, you are not testing code; you are testing intention

I just had to get that off my chest.

Testing internal classes without making them public

…with a trick to make private methods testable too.

When doing automatic tests one often wants to get to the internal classes.

Testing internal stuff

The possibly simplest way is to use InternalsVisbleTo and write

in the testee’s AssemblyInfo.cs

Or one can write just before the namespace declaration too

<shrugging shoulders>Thats all there is to it.</shrugging>

The namespace is System.Runtime.CompilerServices.

One can decorate InternalsVisibleTo with keys and stuff to harden who gets to the internals but why bother? As long as it is dotnet some reflection can get pass the threshold anyway.

Testing private stuff

Another way I have used is to make a wrapping class “UT_Customer” or method “UT_Create” that 1) wraps the internal class/method, 2) is public and 3) is clearly marked with something conspicuous like “UT?_”. If a drive by programmer sees a method with a weird name and doesn’t bother to read the xml comments and still uses the method and fails; I consider it his fault, not mine. Not that I would use an undocumented method, no never.

Moq caveat

There is a caveat where interfaces are not visible for Moq as described here.

The symptom is an error message like

Message: Initialization method Base.UnitTests.Command.CommandHandlerTest thre exception.
Castle.DynamicProxy.Generators.GeneratorException:
Castle.DynamicProxy.Generators.GeneratorException: Type Base.Command.IUndoRedoStack[[Base.Command.ICommand, Base, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]] is not public. Can not create proxy for types that are not accessible.

The remedy is to add

Update

I see at Metzianou that one can add build variable stuff like $(AssemblyName) like so:

1
<InternalsVisibleTo Include="$(AssemblyName).Tests" />