构造函数中应放置多少初始化代码？平台依赖测试问题及优化思路

大量初始化代码确实会引发测试问题，尤其是当代码依赖BLE、NFC这类平台特定组件时——就像下面这个例子：

class MyClass{
 late Hardware hardware;

 MyClass()
 {
   hardware = Hardware();        // 依赖平台的对象
   hardware.onEvent.listen(..);  // 订阅硬件事件
    ...
 }
}

测试这个类时，测试环境里没法提供有效的Hardware组件，直接实例化会报错或者出现异常行为：

test('test something', () {
  var myClass = MyClass();// 这里会报错或行为异常
  
   ...
});

核心结论：尽量简化构造函数，更推荐用依赖注入而非单独init函数 #

为什么原代码难测试？

构造函数里直接实例化Hardware，相当于把MyClass和具体的硬件实现硬绑死了，测试时没法替换成模拟对象，自然会因为平台依赖失效出问题。

改进方案1：依赖注入（最推荐）

把Hardware作为构造参数传入，而不是在构造函数里自己创建。这样测试时可以传入一个模拟的Hardware实例，完全控制它的行为：

class MyClass{
  final Hardware hardware;

  // 直接通过构造参数接收硬件实例
  MyClass(this.hardware) {
    // 这里只做和传入实例相关的轻量操作，比如订阅事件
    hardware.onEvent.listen(...);
  }
}

测试代码示例：

test('test something', () {
  // 创建模拟的Hardware对象，自定义它的行为
  final mockHardware = MockHardware();
  // 配置mock的事件流，避免空指针或异常
  when(mockHardware.onEvent).thenAnswer((_) => Stream.empty());
  
  var myClass = MyClass(mockHardware); // 正常初始化，无报错
  // 执行你的测试逻辑
});

改进方案2：使用init方法（仅适用于无法依赖注入的场景）

如果硬件必须在运行时才能初始化（比如需要上下文等动态条件），可以把初始化逻辑移到专门的init方法里，但要注意管理初始化状态，防止重复调用：

class MyClass{
  late Hardware hardware;
  bool _isInitialized = false;

  MyClass();

  Future<void> init() async {
    if (_isInitialized) return;
    hardware = Hardware();
    hardware.onEvent.listen(...);
    _isInitialized = true;
  }
}

测试时你可以手动控制init的调用时机，甚至通过测试专用的setter或者构造函数替换hardware的实现。

总结 #

构造函数应该只做无副作用、不依赖外部环境的轻量初始化——比如赋值传入的参数、初始化简单的内部状态。涉及平台依赖、IO操作、复杂逻辑的初始化，优先用依赖注入解耦，实在不行再移到专门的初始化方法里，这样能大幅提升代码的可测试性和灵活性。

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