优化tests1-5的readme描述

Author: kaokei

tests/test1/README.md

@@ -1,9 +1,18 @@
 ## 测试场景-当前组件访问当前组件的服务
 
-主要测试了 declareProviders 和 useService 可以互相配合。
+### 测试目的
 
-useService 可以获取正确的实例化对象，且实例化对象确实是响应式对象，会自动更新 dom 数据。
+验证在单个组件内声明和使用服务的完整流程，包括：
 
-并且可以触发点击事件，调用对应的事件处理函数。
+1. 使用 `declareProviders` 注册服务提供者和 `useService` 获取服务实例的正确协作
+2. 验证获取的服务实例具备完整的类型和功能
+3. 测试服务实例的响应式特性及其与 DOM 更新的联动
 
-service 中的 getter 属性可以看作是没有缓存的 computed 属性。
+### 测试要点
+
+- 服务实例成功注入并可在组件中被正确访问
+- 服务中的普通属性（如 `count`、`age`）变更能触发视图更新
+- 服务中的 getter 属性（如 `name`）能够动态计算并随依赖变化而更新
+- 服务中的 computed 属性（如 `computedName`）能正确工作并保持响应性
+- 服务方法（如 `increaseCount`、`increaseAge`）可以通过事件正确调用并影响状态
+- `@PostConstruct` 装饰器能正确执行初始化逻辑

tests/test2/README.md

@@ -1,17 +1,32 @@
-## 测试场景-当前组件的服务访问当前组件
+## 测试场景-组件与服务的多种交互方式
 
-```
-@Inject(CURRENT_COMPONENT)
-public component: ComponentInternalInstance | null = null;
-```
+### 测试目的
 
-测试了在服务中获取当前组件的功能，主要功能可以获取 props 或者发送事件
+测试组件和服务之间的交互方式及数据流转，没有使用组件注入功能（CURRENT_COMPONENT 已经被移除），而是使用显式传递数据的方式。
 
-```
-this.component.props
-this.component.emit()
+组件应该主动去更新服务的数据，而不是服务直接读取组件的数据。
+比如在组件中 watch props 的变更，同步数据到服务中。
 
-// 还可以获取组件的defineExpose的数据，但是不建议使用
-// 因为所有数据都在服务中，服务可以通过依赖注入引用其他服务
-this.component.exposeProxy
-```
+服务中也不应该直接调用组件的 emit，而是在组件中调用服务的方法，同时处理 emit 逻辑。
+也就是在组件中定义 event handler，然后在 template 中使用该 handler。
+
+### 测试要点
+
+1. **组件主动传递数据到服务**
+
+   - 通过调用服务方法（如`setComponentMsg`）将组件属性传递给服务
+
+2. **组件与服务共同处理事件**
+
+   - 服务负责状态更新（如`increaseCount`）
+   - 组件基于服务状态发送事件（如`emit('count', service.count)`）
+
+3. **跨组件机制**
+
+   - 父组件通过 ref 引用子组件暴露的服务实例
+   - 通过父组件直接操作子组件的服务实例
+
+4. **服务状态的多重响应性**
+   - 服务中的 getter 属性和 computed 属性能根据组件传入的数据动态计算
+
+这个测试用例演示了在不直接在服务中注入组件实例的情况下，如何实现组件与服务之间的高效交互。

tests/test3/README.md

@@ -1,5 +1,21 @@
-## 测试场景-当前组件的服务访问另一个当前组件的服务
+## 测试场景-服务之间的依赖注入
 
-declareProviders 一次性声明多个 Class。
+### 测试目的
 
-useService 分别获取 demoService 和 otherService，并且 demoService 依赖 otherService。
+验证在同一个组件中声明多个服务，并实现服务之间的依赖注入与交互。
+
+### 测试要点
+
+1. **多服务一次性声明**
+   - 通过 `declareProviders([DemoService, OtherService])` 同时声明多个服务提供者
+
+2. **服务之间的依赖注入**
+   - 使用 `@Inject(new LazyToken(() => OtherService))` 将 OtherService 注入到 DemoService 中
+   - 验证注入的服务实例与直接使用 `useService` 获取的是同一实例
+
+3. **服务之间的数据传递与计算**
+   - DemoService 中的计算属性 `sum` 依赖于两个服务的状态
+   - 当任一服务的状态变化时，计算属性能正确更新
+
+4. **服务实例的相互独立性**
+   - 每个服务维护自己的状态，但可以通过依赖关系相互访问

tests/test4/README.md

@@ -1,5 +1,24 @@
-## 测试场景-子组件访问父组件服务+子组件服务访问父组件服务
+## 测试场景-多层级组件中的服务共享与依赖注入
 
-测试用例是3层组件结构。DemoComp --> ParentComp --> ChildComp
+### 测试目的
 
-证明子组件可以正确访问父组件的服务，以及子组件的服务也可以正确访问父组件的服务。
+验证在多层级嵌套组件（DemoComp → ParentComp → ChildComp）中，服务实例的依赖注入、逻辑共享和响应式更新机制。
+
+### 测试要点
+
+1. **服务实例的跨组件共享**
+   - 子组件直接使用 `useService` 访问父/祖父组件中声明的服务
+   - 确认得到的实例与父/祖父组件中的是同一个实例（服务单例模式）
+
+2. **服务之间的依赖注入**
+   - ParentService 通过 `@Inject` 注入 DemoService
+   - ChildService 通过 `@Inject` 同时注入 ParentService 和 DemoService
+   - 服务间的依赖关系与组件嵌套层级一致
+
+3. **不同组件层级对服务的操作与响应**
+   - 从任何层级的组件修改服务状态，所有引用该服务的组件都能同步响应更新
+   - 无论通过直接引用还是注入引用，服务状态均可保持一致
+
+4. **服务实例在多层级组件中的唯一性**
+   - 每个服务类在整个组件树中只有一个实例
+   - 包括通过子组件服务中引用的父组件服务实例也与直接使用 `useService` 获取的相同

tests/test5/README.md

@@ -1,5 +1,25 @@
-## 测试场景-使用new Token生成token
+## 测试场景-Token系统与TokenType类型推导
 
-useService可以自动识别token对应的服务的类型
+### 测试目的
 
-@Inject(token)中可以借助TokenType获取实际服务的类型
+验证 Token 系统的使用，包括 Token 创建、类型推导和依赖注入功能，以及更灵活的服务注册与解析方式。
+
+### 测试要点
+
+1. **Token 创建与使用**
+   - 使用 `new Token<ServiceType>('name')` 创建带类型的服务标记
+   - 基于命名空间（如 `TYPES` 对象）组织多个 Token
+
+2. **容器绑定 API**
+   - 使用 `declareProviders` 的函数式 API
+   - 通过 `con.bind(token).to(ServiceClass)` 实现 Token 到实际服务类的绑定
+   
+3. **TokenType 类型推导**
+   - `useService(TYPES.DemoService)` 自动返回正确类型的服务实例
+   - `@Inject(TYPES.OtherService)` 结合 `TokenType<typeof TYPES.OtherService>` 实现注入属性的类型推导
+
+4. **服务间依赖关系**
+   - 在 DemoService 中通过 Token 注入 OtherService
+   - 利用强类型节省手动类型转换，通过 TokenType 可直接访问被注入服务的属性和方法
+   
+通过这种方式，可以更灵活地管理服务依赖和注入，并且保持完整的类型推导支持。