# 总-课程安排 > 游戏化，可以重塑人类积极的未来。 —— 《游戏改变世界》 本次实战营总共有 5 个副本，而每个副本都包括以下几个部分。接下来，我会跟你一一介绍每个部分的意思： 一、**副本简介** 当然就是对项目「简单介绍」的“缩写”。😉 二、**副本挑战** 该部分就是我的教学目标，也是你的学习目标。准确来说，会为你描述该章节的练习要求，期望你能够反复练习，不断突破自己。 三、**时长限制** 这是我给你的建议学习总时长，比如 **4 小时**，不过我期望你最好跟随大家的脚本，把学习时间合理分配到 21 天训练营的每一天。每天坚持学习、坚持练习，获取反馈，才能够达到最佳的学习效果。每个副本的 BOSS 都会周期性回血，还不快去打败它！ > NPC 温馨提示：在规定时间内才能获得 BOSS 掉落的物品哦，当然还有自不必说的，不要抄袭作业。我也不建议你在做的同时，就去参考别人的答案，或者是代码库的完成分支。 四、**副本奖励** 这部分就是在你学完课程，打败 BOSS 之后，你就将点亮的技能点。当然，这也是你在学习过程中的能力目标，还记得以终为始吗？你要把灵活应用该技能作你怎么把饭热起来啦，不是吃蛋炒饭吗？不知道怎么办啊。为目标，而不是单纯的打败 BOSS，我更期望的是看到你在平常的开发工作中运用这些技能，那才是真的学会了呀！ 五、**BOSS 掉落** 当然啦，每个副本刷完，打败了传说中的 BOSS，拿着“材料”证明你就可以到我（不是 NPC）这儿来领取一些奖励：可能是一个红包 🧧，也可能是我总结好的一点私货儿，当然也可以获得一次一对一提问的机会，当然，更希望的是能和你成为朋友。 ## 副本 1. FizzBuzz 数字游戏 * 代码仓库： * 快速入口： * 最终效果： ### 目的：认识和理解 TDD 流程 * 使用 Jest 测试基本语法(`test()`, `expect().toEqual()`) * 理解单元测试 `given-when-then` 三段式写法 * 熟悉 React 函数式组件 + React `Hook` 的组件写法 * 使用 Testing Library 如何测试组件单元 ## 副本 2. MarsRover 火星漫游者 * 代码仓库： * 快速入口： * 最终效果： ### 目的：TDD Cycle 各环节的进阶学习 * 任务分解：Tasking 如何转化为 TestCase * 开始接触重构，坏味道 & IDE 具体操作手法 * 使用“拆分阶段”手法重构，同时体现数据与 UI 分离 * 引出命令者模式，再引出 Redux 与 CQRS 架构 ## 副本 3. CommentBox 留言板 * 代码仓库： * 快速入口： * 最终效果： ### 目的：组件级别的测试基础与要点 * 学习 E2E 级别 Cypress 更直观的 UI TDD 测试路径 * 熟悉单元级别 Testing Library 的行为测试方法与理念 * 由外至内，完整的前端测试驱动开发 (TDD) “套路” * 学习视觉级别 TDD 验证，重构到 Storybook，穷举 UI Stories * UI 重构的挑战：视觉测试，而不是基于 className 或 style 的测试 ## 副本 4. Bookshelf 魔术书架 * 代码仓库： * 快速入口： * 最终效果： ### 目的：组件拆分，API 集成基础 * 集成 Redux，数据 model 层面的测试 `redux-saga-test-plan` * 学习 Jest Mock API 及异步测试方法 (`mock()` `fn()` `spyOn()`) * API 契约测试，利用 Pact 简化**前后端集成**开发策略 * selectors 与 `useSelector`，最简单的纯 JavaScript 逻辑单测 * services 层测试，直接 mock 数据返回，API 请求则留给契约测试 * 完善测试策略，utils，也是最简单的纯 JavaScript 单元测试 ## 副本 5. ShoppingCart 购物车 * 代码仓库： * 快速入口： * 最终效果： ### 目的：综合应用，测试驱动开发（TDD）工程实践 * 从需求出发 BDD，ATDD，SpecByExample, UserStory * 完整的 TDD 实例，完成页面 UI 拆分和组件开发，Visual Testing * 多种用户角色参与，全流程的「商品管理 + 购物车购买」测试路径 * 建立在充分覆盖且运行快速的自动化测试基础上的持续集成/持续交付 涵盖所有维度的测试及其应用测试策略： 1. 页面级别：用户 E2E 行为 Cypress 搞定 @done(2020-02-16) 2. 组件级别：交互逻辑 jest+testing-library 搞定 @done(2020-02-16) 3. 组件级别：UI 样式 story+snapshot 搞定 @done(2020-02-16) 4. 数据流 model：redux-saga-test-plan 搞定 @done(2020-02-16) 5. selectors， 最简单的纯 JavaScript 逻辑单测 @done(2020-02-16) 6. services，直接 mock 数据返回，API 请求则留给契约测试 @done(2020-02-16) 7. utils，也是最简单的纯 JavaScript 单元测试 @done(2020-02-16) 8. API 契约测试，[Pact 接口验证与 Mock 数据返回](https://docs.pact.io/5-minute-getting-started-guide) @done(2020-02-16) ## 增量式，难度递增的副本阶梯 从教学角度来说，我为你设置的副本的项目需求是变化的，但可以是增量式的，逐步让你体验自动化测试的重要性以及 TDD 所能带来的好处。更重要的是，我会更清晰得告诉你痛点和障碍在哪里，需要你在刻意练习的过程中，逐步克服它。 就目前来说，你的**愿望(Wish)**是期望自己能够顺利通过本次实战营，挑战成功并获得 TDD 的编码能力（否则你也不会看到我的这句话啦）。那么，你能想象的，实现这个愿望的最好结果是什么样子的呢？ 请充分想象…自己已经掌握了 TDD 时「唯快不破」的编码状态， 用三到六个字概括并写下这个**结果(Outcome)**: 想象... `_____________` 学会 TDD 之后，会变成效率提升 10x 倍的程序员吗？那么，阻碍你实现愿望的，最主要的内心障碍是什么? 用三到六个字概括并写下这个**障碍(Obstacle)**: 想象... `_____________` 那么，你能做什么去克服这个障碍? 请用三到六个字概括并写下这个行动**计划(Plan)**或想法: 填入以下空白: 如果... `_____________` (你的障碍)，那我就会... `_____________` (克服障碍的行动或想法) 再一次想象:如果...(障碍),那我就会...(行动)。 ## WOOP 工具箱与心理 Hack 😁 抱歉刚刚“套路”了你这么久，但是我衷心得期望你刚刚有被我“套路”到。其实这是一个系统性的方法：愿望、结果、障碍、计划(简称 WOOP)，用以提高内心动力以及改变行为。WOOP 在科学上被称之为“心理对比与执行意图”(Mental Contrasting with Implementation Intentions, MCII) 那么，在今后的副本练习当中，你可以用 WOOP 卡片提醒自己 WOOP 的四个步骤: ![WOOP 卡片](/files/-M0DoayqdPAHNBDB5Oez) W 先指定一个既有挑战性，又有可行性的愿望。 O 然后找到最佳结果，并想象这个结果。 O 然后找到你最主要的的内心障碍，并想象这个障碍。 P 最后，制定一个“如果-就”（if-then）计划去克服这个障碍。 > WOOP 基于 20 年的动机科学研究，提出了一个独特而令人惊讶的理念：我们所认为的障碍实际上可以帮助我们实现自己的愿望。 WOOP 倡导我们憧憬对未来的梦想的同时，分析我们内心有哪些障碍在 阻止我们实现这些梦想。WOOP 给了我们方向和力量来实现我们的愿望，解决我们的担忧。 说实在的，从认知角度来看，这跟测试驱动开发（TDD）的原理是一样的呢，😁 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://jimmylv.gitbook.io/tdd-frontend/02-course.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.