Composer扩展包单元测试需确保自动加载、命名空间和测试入口三者对齐：autoload-dev配置必须匹配tests/路径与命名空间，phpunit.xml.dist中bootstrap须设为vendor/autoload.php，测试类名、文件名及方法命名须符合PHPUnit默认规则，且可复用测试工具类应置于src/并声明在autoload中。

Composer扩展包的单元测试不是“加个phpunit就行”，关键在自动加载、命名空间和测试入口三者对齐；否则Class not found或Cannot declare class错误会反复出现。

composer.json 的 autoload-dev 配置必须匹配测试类路径

很多包作者把tests/目录写进autoload（生产自动加载），这是错的——测试代码不该被生产环境加载。正确做法是只进autoload-dev，且路径与命名空间严格对应。

• "autoload-dev": { "psr-4": { "MyVendor\MyPackage\Tests\": "tests/" } }
• 对应测试文件路径：tests/Unit/CalculatorTest.php
• 对应类声明：namespace MyVendorMyPackageTestsUnit;
• 运行composer dump-autoload后，vendor/autoload.php才能正确解析测试类

phpunit.xml.dist 中的 bootstrap 必须指向 vendor/autoload.php

PHPUnit 启动时若没加载 Composer 自动加载器，所有被测类和测试类都会报Class not found。常见错误是误设为src/autoload.php或留空。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 必须显式指定：bootstrap="vendor/autoload.php"
• 如果扩展包依赖其他开发组件（如mockery/mockery），也要确保它们已安装在require-dev中
• 避免用--bootstrap命令行参数覆盖配置，容易遗漏在CI中

测试类命名和方法命名要符合 PHPUnit 默认规则

不靠配置硬改规则，是最省事的实践方式。PHPUnit 默认只扫描以Test结尾的类、以test开头或带@test注解的方法。

• 文件名必须是CalculatorTest.php，不能叫TestCalculator.php或calculator_test.php
• 类名必须是CalculatorTest，且继承PHPUnitFrameworkTestCase
• 方法名推荐testCanAddTwoNumbers()，避免canAddTwoNumbers()（除非加@test）
• 别在setUp()里做耗时操作（如数据库连接），单元测试应轻量、可重复

本地开发时用 path repository 模拟真实依赖场景

直接在包目录下跑./vendor/bin/phpunit只能验证语法，无法暴露“被其他项目引用时是否能加载”的问题。真正可靠的测试，得模拟下游项目如何使用你这个包。

• 在下游项目的composer.json中添加repositories：

  "repositories": [
    {
      "type": "path",
      "url": "../my-package"
    }
  ]

• 然后composer require my-vendor/my-package:dev-main
• 再在下游项目里写一个测试，尝试new MyVendorMyPackageSomeService()——这才是真实集成场景

最容易被忽略的是：扩展包自身的tests/目录不会被下游项目自动加载，所以所有可复用的测试工具类（比如共享的TestCase基类）必须放进src/并声明在autoload里，否则下游无法继承。