Angular5单元测试Mock getAttribute时遇空值读取报错问题

我太懂你这种卡在报错环节的憋屈了——这个TypeError的根源很明确：你的测试环境里，#elementID下面根本没渲染出任何<li>元素，所以querySelector找不到东西，自然就报“Cannot read property 'getAttribute' of null”了。结合你用的是Angular的*ngFor，问题大概率出在测试时没给组件喂对数据，或者测试模块配置不到位。

咱们一步步来解决：

1. 先搞清楚为什么<li>没渲染 #

你的<li>是靠*ngFor="let item of items"生成的，如果测试时items是空数组，*ngFor直接不会生成任何<li>标签，那querySelector肯定返回null。另外[attr.disabled]="data.isDisabled"也依赖data对象，要是data没初始化，也可能出问题。

2. 方案一：让真实元素渲染出来（最贴合实际场景） #

在测试用例里给组件的items和data赋值，触发变更检测让模板渲染：

// 在beforeEach或者具体的it块里初始化数据
beforeEach(() => {
  fixture = TestBed.createComponent(YourComponent);
  component = fixture.componentInstance;
  // 给items塞至少一个元素，让*ngFor能生成<li>
  component.items = [{ id: 1, content: '测试项' }];
  // 给data赋值，设置isDisabled的状态
  component.data = { isDisabled: false };
  fixture.detectChanges(); // 触发变更检测，让模板更新
});

另外别忘了，*ngFor属于CommonModule，如果你的测试模块没导入它，模板编译会失败，元素也不会渲染，所以要确保测试模块配置正确：

beforeEach(async () => {
  await TestBed.configureTestingModule({
    declarations: [YourComponent],
    imports: [CommonModule] // 必须导入这个模块！
  }).compileComponents();
});

3. 方案二：直接mock查询结果（快速跳过DOM渲染） #

如果你只是想测试那个if语句的逻辑，不想折腾真实DOM，可以直接mockdocument.body.querySelector的返回值，用jasmine或者jest的spy就行：

it('应该执行disabled为false时的逻辑', () => {
  // 模拟一个带getAttribute方法的<li>元素
  const mockLiElement = {
    getAttribute: jasmine.createSpy('getAttribute').and.returnValue('false')
  };
  // 把querySelector的返回值换成咱们的模拟元素
  spyOn(document.body, 'querySelector').and.returnValue(mockLiElement as HTMLElement);
  
  // 调用你要测试的方法
  component.yourTargetMethod();
  
  // 断言后续逻辑是否执行，比如某个函数被调用
  expect(component.someLogicFunction).toHaveBeenCalled();
});

4. 更推荐的Angular测试方式：用DebugElement查找元素 #

其实在Angular测试里，官方更推荐用fixture.debugElement来查找元素，而不是直接操作document，这样更可控，也符合Angular的测试规范：

it('应该正确识别disabled属性并执行逻辑', () => {
  component.items = [{ id: 1 }];
  component.data = { isDisabled: false };
  fixture.detectChanges();
  
  // 用DebugElement查找元素
  const liElement = fixture.debugElement.query(By.css('#elementID li'));
  expect(liElement.nativeElement.getAttribute('disabled')).toBe('false');
  
  // 调用目标方法，测试后续逻辑
  component.yourTargetMethod();
  // ...这里写你的断言，比如某个变量被修改，或者某个方法被调用
});

不管选哪种方案，核心都是让querySelector能拿到一个非null的元素（要么真实渲染，要么模拟），这样就能顺利跳过报错，测试你真正关心的if语句后的逻辑了。

内容的提问来源于stack exchange，提问作者justKeepCodin