我们需要从访客那里收集哪些信息，以便将其登记为电子邮件通讯的订阅者？
- 电子邮件地址：这是最基本的要求，因为我们需要通过电子邮件地址向订阅者发送内容。
- 姓名：虽然这不是强制性的，但我们希望收集一个名字，以便在电子邮件中个性化问候（例如，“您好 {{subscriber.name}}!”）。这有助于增加邮件的亲和力和互动性。
为什么收集这些信息？
- 电子邮件地址：这是发送消息的唯一标识符。
- 姓名：用于个性化邮件，使订阅者感到更亲切。我们不强制要求真实姓名，允许用户使用任何他们喜欢的标识符（例如，coderLZ）。
表单提交的编码方式
假设数据是通过HTML表单收集的，并通过POST请求传递给后端API，表单数据的编码方式可以选择 application/x-www-form-urlencoded。这是最常见的表单数据编码方式，适用于大多数简单的表单提交场景。
示例HTML表单
<form action="/subscribe" method="post">
<label for="email">电子邮件地址:</label>
<input type="email" id="email" name="email" required>
<label for="name">姓名 (可选):</label>
<input type="text" id="name" name="name">
<button type="submit">订阅</button>
</form>后端API接收的数据格式
当表单提交时，数据将以 application/x-www-form-urlencoded 格式编码，并通过POST请求的请求体（body）传递给后端API，比如
email=example%40example.com&name=DenverCoder9通常在URL编码中使用%20替换空格，%40替换@符号,以确保URL的标准化、兼容性和安全性。通过URL编码，可以确保各种字符在URL中正确传输和解析。
将需求转化为测试用例，在实际开发过程中也是如此，测试先行
测试用例
- 验证电子邮件地址的有效性
- 描述：确保用户提供的电子邮件地址是有效的。
- 测试用例：
- 输入：email=example@example.com
- 期望输出：订阅成功。
- 输入：email=invalidemail
- 期望输出：显示错误消息，提示电子邮件格式无效。
- 验证姓名字段的灵活性
- 描述：确保用户可以使用任何形式的姓名，包括空值。
- 测试用例：
- 输入：email=example@example.com&name=John Doe
- 期望输出：订阅成功。
- 输入：email=example@example.com&name=DenverCoder9
- 期望输出：订阅成功。
- 输入：email=example@example.com&name=
- 期望输出：订阅成功，姓名字段为空。
- 验证表单提交的编码方式
- 描述：确保表单数据以 application/x-www-form-urlencoded 格式正确编码。
- 测试用例：
- 输入：email=example%40example.com&name=John%20Doe
- 期望输出：订阅成功，电子邮件地址和姓名正确解析。
- 验证重复订阅
- 描述：确保同一电子邮件地址不能多次订阅。
- 测试用例：
- 输入：第一次订阅 email=example@example.com&name=John Doe
- 期望输出：订阅成功。
- 输入：第二次订阅 email=example@example.com&name=John Doe
- 期望输出：显示错误消息，提示该电子邮件地址已订阅。
- 验证错误处理
- 描述：确保系统能够正确处理各种错误情况。
- 测试用例：
- 输入：email=example@example.com&name=
- 期望输出：订阅成功，姓名字段为空。
- 输入：email=&name=John Doe
- 期望输出：显示错误消息，提示电子邮件地址不能为空。
- 输入：email=example@example.com&name=<>
- 期望输出：显示错误消息，提示姓名字段包含非法字符。
编写测试用例代码
本文结合表驱动测试（Table-Driven Testing）方法，它通过使用一个数据表来组织测试用例。每个测试用例通常包含输入数据、预期输出结果以及可能的其他信息，如测试描述或标签。这种方法使得测试代码更加简洁、易于理解和维护，同时也方便扩展新的测试用例。
表驱动测试的优势
- 代码简洁：通过将测试用例组织成表格形式，可以避免大量的重复代码，使测试逻辑更加清晰。
- 易于维护：当需要添加新的测试用例或修改现有测试用例时，只需更新表格中的数据，而不需要改动测试逻辑。
- 便于扩展：可以轻松地向表格中添加新的行，以涵盖更多的测试场景。
- 更好的可读性：将测试用例组织成表格形式，使得测试意图更加明确，更容易理解。
///! src/health_check.rs
#[tokio::test]
async fn subscribe_returns_a_200_for_valid_form_data() {
let app_address = spawn_app();
let client = reqwest::Client::new();
let body = "name=le%20guin&email=ursula_le_guin%40gmail.com";
let response = client
.post(&format!("{}/subscriptions", &app_address))
.header("Content-Type", "application/x-www-form-urlencoded")
.body(body)
.send()
.await
.expect("Failed to execute request .");
//此处我们希望返回200，但是很明显/subscriptions路径根本不存在，应该返回404
assert_eq!(200, response.status().as_u16());
}
#[tokio::test]
async fn subscribe_returns_a_400_when_data_is_missing() {
let app_address = spawn_app();
let client = reqwest::Client::new();
///```test_cases：定义了一个包含多个测试用例的向量。每个测试用例是一个元组，包含两个字符串：
/// invalid_body：无效的请求体，用于模拟缺少某些必要字段的情况。
///```error_message：描述该测试用例的错误信息，用于在断言失败时提供更详细的错误信息。
let test_cases = vec![
("name=le%20guin", "missing the email"),
("email=ursula_le_guin%40gmail.com", "missing the name"),
("", "missing both name and email"),
];
for (invalid_body, error_message) in test_cases {
let response = client
.post(&format!("{}/subscriptions", &app_address))
.header("Content-Type", "application/x-www-form-urlencoded")
.body(invalid_body)
.send()
.await
.expect("Failed to execute request.");
assert_eq!(
400,
response.status().as_u16(),
"The API did not fail with 400 bad Request when the payload was {}.",
error_message
);
}
}
这段代码通过表驱动测试的方法，验证了一个 HTTP API 在接收到缺少必要数据的请求时是否会正确返回 400 Bad Request 状态码。每个测试用例都包含一个无效的请求体和一个描述性的错误信息，以便在断言失败时提供详细的错误提示。虽然并没有覆盖到所有的测试用例，但是这种测试方法不仅提高了代码的可读性和可维护性，还确保了 API 的健壮性。
下一节我们将开始实现/subscriptions 功能
