test: update unit tests and enable Debug-only build

[pengfeixx]

Re-enable test directory with Debug build guard, update test code to use new DSchedule API, disable segfault-prone setDragPixmap test.

重新启用测试目录并限制仅在 Debug 模式构建，更新测试代码适配
新的 DSchedule 接口，禁用导致段错误的 setDragPixmap 测试用例。

Log: 更新单元测试代码，仅在Debug模式构建测试
Influence: Release构建不再包含测试代码，加快构建速度；Debug模式下可正常执行单元测试。

[sourcery-ai]

Sorry @pengfeixx, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[deepin-ci-robot]

deepin pr auto review

这份 Git Diff 主要涉及对 dde-calendar 项目单元测试的全面修复和重构。由于业务代码进行了大规模重构（例如将 ScheduleDataInfo 替换为 DSchedule::Ptr，将 CalendarScheduler 替换为 DAccountModule 等），测试代码也随之进行了适配，并重新启用了被注释掉的 CMake 测试构建逻辑。

以下是对该 Diff 的详细代码审查意见，分为语法逻辑、代码质量、代码性能和代码安全四个方面：

一、 语法与逻辑

1. CMake 构建类型判断逻辑存在隐患 (CMakeLists.txt)

   if(CMAKE_BUILD_TYPE MATCHES Debug)
     ADD_SUBDIRECTORY(tests)
   endif()

   • 问题：MATCHES 使用的是正则表达式匹配。如果用户指定的构建类型是 Debug、RelWithDebInfo 或者是自定义的 MyDebug，这可能会产生意料之外的结果。更重要的是，多配置生成器（如 Visual Studio, Xcode）在配置阶段 CMAKE_BUILD_TYPE 通常为空，这会导致测试永远无法在这些 IDE 中构建。
   • 建议：如果仅允许单配置生成器构建测试，建议使用严格的字符串比较：if(CMAKE_BUILD_TYPE STREQUAL "Debug")。若需支持多配置生成器，应使用生成器表达式：add_subdirectory(tests $<CONFIG:Debug>) 或通过独立的 CMake 选项（如 BUILD_TESTING）来控制。

2. Qt6 兼容性逻辑存在遗漏 (test_todaybutton.cpp)

   #if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0)
       QEnterEvent enterEvent(QPointF(10,2), QPointF(11,3), QPointF(10,2));
   #else
       QEnterEvent enterEvent(QPointF(10,2), QPointF(11,3), QPointF(12,4));
   #endif

   • 问题：Qt5 和 Qt6 的 QEnterEvent 构造函数签名确实发生了变化，但这里只做了局部修复。项目中其他测试文件（如 test_schedulesearchview.cpp 中的 QEnterEvent event(QPointF(0, 0), QPointF(0, 0), QPointF(0, 0));）没有加上版本判断，在 Qt5 环境下编译可能会报错。
   • 建议：全局搜索并统一 QEnterEvent 的实例化方式，确保 Qt5/Qt6 的兼容性处理一致。

3. QSqlQuery Stub 函数签名不匹配风险 (test_schedulerdatabase.h)

   stub.set((QVariant(QSqlQuery::*)(int)const)ADDR(QSqlQuery, value), schedulerdatabase_stub_value);

   • 问题：在 Qt6 中，QSqlQuery::value() 的参数由 const QString& 变为了 int（按索引获取）。虽然这里做了强制转换，但如果底层依赖的 Qt 版本不同，ADDR 宏获取的函数地址可能因为隐式重载决议而指向错误的符号。
   • 建议：确保编译环境与 Stub 的函数签名严格对应，或者通过更高层的数据库接口 Mock 来避免直接 Stub 底层 Qt 类。

二、 代码质量

1. 大量被注释掉的测试代码 (test_monthbrefwidget.cpp, test_scheduleremindwidget.cpp 等)

   • 问题：Diff 中移除了大量过时的测试用例（如 setDate, setTheMe 等），但有些地方只是将它们注释掉（如 // mMonthBrefWidget->render(&pixmap);，// TEST_F(...)）。这会让测试文件充斥着死代码，降低可读性。
   • 建议：版本控制系统（Git）已经保存了历史，对于不再需要的测试用例或逻辑，应直接删除而非注释。对于因运行时依赖缺失而跳过的 render() 调用，应使用 GTest 的 GTEST_SKIP() 宏明确标记跳过原因，而不是默默注释掉断言。

2. 硬编码的 Skip 列表 (test-prj-running.sh)

   CLIENT_SKIP="--gtest_filter=-*getPixmap*:test_schedulesearchview.contextMenuEvent*..."

   • 问题：将已知崩溃的测试用例硬编码在运行脚本中是一种 Anti-pattern。随着代码修复，这个列表很容易被遗忘更新，导致本该运行的测试被永久跳过。
   • 建议：对于已知缺陷，应在测试代码内部使用 DISABLED_ 前缀（如 Diff 中 DISABLED_setDragPixmap_01 就做得很好），或使用 GTEST_SKIP()。这样测试报告中会明确显示被跳过的测试及其原因，而无需外部脚本干预。

3. 魔法字符串与数字 (test_calendarscheduler.cpp)

   mCalendar->notifyMsgHanding("1", 1);
   // ...
   mCalendar->setSyncFreq("0");

   • 问题：测试数据中充斥着 "1", "0" 等魔法字符串，缺乏语义，难以让人理解测试意图。
   • 建议：使用常量或更具描述性的测试数据，如 mCalendar->notifyMsgHanding(VALID_ACCOUNT_ID, NOTIFY_NEW_EVENT);。

三、 代码性能

1. 测试夹具中的重复初始化 (test_monthbrefwidget.h, test_scheduleremindwidget.cpp)

   • 问题：在每个 TEST_F 中都会执行 SetUp 和 TearDown，如果创建 MonthBrefWidget 或 DSchedule 涉及复杂的 UI 初始化或 IO 操作，会显著拖慢测试执行速度。
   • 建议：如果对象的状态在测试间不会被破坏，可以考虑使用静态构造（SetUpTestSuite）来复用对象，减少 UI 控件的重复创建开销。

2. getScheduleDInfo() 等辅助函数频繁构造对象 (test_schedulesearchview.cpp)

   • 问题：每次调用辅助函数都会 new 出多个 DSchedule 对象并组装集合，在同一个测试套件中可能产生大量重复的内存分配。
   • 建议：考虑使用工厂模式或在 SetUpTestSuite 中预生成测试数据，测试中按需拷贝，减少堆内存分配次数。

四、 代码安全

1. 测试代码中的裸指针与内存泄漏风险 (test_monthbrefwidget.cpp)

   void test_monthbrefwidget::SetUp() {
       mGlobalData = new MonthBrefWidget::GlobalData();
       mMonthBrefWidget = new MonthBrefWidget();
       mMonthDayRect = new CMonthDayRectWidget(mGlobalData);
   }

   • 问题：如果在 SetUp 中 new MonthBrefWidget() 抛出异常，mGlobalData 将发生内存泄漏；如果 new CMonthDayRectWidget() 抛出异常，前两者都会泄漏。测试代码同样需要保证异常安全。
   • 建议：在测试代码中也应尽量使用智能指针（如 std::unique_ptr），或者确保构造顺序安全，并在 TearDown 中严谨地逆序释放。

2. Stub 框架的线程安全与全局状态 (stub.h 的使用)

   • 问题：stub.set(ADDR(...), ...) 这种方式通常修改的是全局函数表或虚函数表。如果 GTest 并发执行测试（虽然目前 GTest 默认串行，但未来可能并行），这种全局 Stub 会导致严重的竞态条件和不可预测的行为。
   • 建议：确保测试以串行方式运行。如果项目未来考虑并行测试，需要重构依赖注入方式，避免使用全局函数 Hook 工具。

3. 脚本中的容错处理 (test-prj-running.sh)

   cp -r asan*.log* ../$reportdir/asan_dde-calendar.log 2>/dev/null || true

   • 优点：这里增加了 2>/dev/null || true，防止在没有 asan 日志时脚本意外退出，这是一个很好的安全改进。
   • 建议：继续保持这种防御性编程风格。

总结

该 Diff 成功地将停滞已久的单元测试与最新重构的业务代码进行了对齐，工作量和难度都较大。重新开启 Debug 模式下的测试构建是非常正确的决定。但需要注意：

1. 清理死代码：删除注释掉的测试和 render() 调用，改用 GTEST_SKIP() 或 DISABLED_。
2. 修复 CMake 逻辑：将 MATCHES Debug 改为更严谨的条件判断。
3. 统一 Qt 版本兼容处理：排查所有 QEnterEvent 等跨版本变更的 API，统一添加版本控制宏。
4. 提升测试代码的异常安全：在 SetUp/TearDown 中使用智能指针管理测试对象的生命周期。

[github-actions]

Note

[静态代码检查]

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: lzwind, pengfeixx

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[deepin-bot]

TAG Bot

New tag: 6.5.41
DISTRIBUTION: unstable
Suggest: synchronizing this PR through rebase #335