为什么这个带有 post 请求的集成测试失败了？
Why does this integration test with post request fail?
我已经为写入两个 tables/models 的注册表单编写了集成测试。它失败并显示消息 "Organization.count" didn't change by 1。但是，有没有一种方法可以查看测试失败的错误消息类型（该表单在开发中有效，尽管显示错误消息存在问题，所以我不明白测试失败的原因）。所以我的意思是如果你在服务器上做了同样的事情你会看到错误消息来帮助我找出为什么它没有保存 organization/user.
test "valid combined organization user signup" do
get new_path
assert_template 'organizations/new'
assert_difference ['Organization.count', 'User.count'], 1 do
post organizations_path, organization: { name: "Abc1",
bag: "aef1",
users_attributes: [email: "test@test.br",
username: "abc1",
password: "foobar",
password_confirmation: "foobar"] }
end
end
也许测试日志可以提供帮助？我在这里看到 IS NULL LIMIT 用户电子邮件和用户名。鉴于测试语法，我不明白为什么...
Started POST "/organizations"
Processing by OrganizationsController#create as HTML
Parameters: {"organization"=>{"name"=>"Abc def 1", "bag"=>"adef1", "users_attributes"=>[{"email"=>"adef1@uniqu.br", "username"=>"adef1", "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]"}]}}
[1m[36m (0.2ms)[0m [1mSAVEPOINT active_record_1[0m
[1m[35mOrganization Exists (0.6ms)[0m SELECT 1 AS one FROM "organizations" WHERE LOWER("organizations"."name") = LOWER('Abc def 1') LIMIT 1
[1m[36mOrganization Exists (0.3ms)[0m [1mSELECT 1 AS one FROM "organizations" WHERE LOWER("organizations"."bag") = LOWER('adef1') LIMIT 1[0m
[1m[35mOrganization Exists (0.3ms)[0m SELECT 1 AS one FROM "organizations" WHERE LOWER("organizations"."name") = LOWER('Abc def 1') LIMIT 1
[1m[36mOrganization Exists (0.3ms)[0m [1mSELECT 1 AS one FROM "organizations" WHERE LOWER("organizations"."bag") = LOWER('adef1') LIMIT 1[0m
[1m[35mSQL (0.4ms)[0m INSERT INTO "organizations" ("name", "bag", "created_at", "updated_at") VALUES (, , , ) RETURNING "id" [["name", "Abc def 1"], ["bag", "adef1"], ["created_at", "2015-06-27 16:28:56.179789"], ["updated_at", "2015-06-27 16:28:56.179789"]]
[1m[36mUser Exists (0.6ms)[0m [1mSELECT 1 AS one FROM "users" WHERE "users"."email" IS NULL LIMIT 1[0m
[1m[35m (0.6ms)[0m SELECT "users"."email" FROM "users" ORDER BY "users"."username" ASC
[1m[36mUser Exists (0.2ms)[0m [1mSELECT 1 AS one FROM "users" WHERE "users"."username" IS NULL LIMIT 1[0m
[1m[35m (0.2ms)[0m ROLLBACK TO SAVEPOINT active_record_1
控制器方法post在这里编辑：whosebug.com/q/31072646/4499505（organizations_path指创建方法）
如果我将测试日志与开发日志进行比较（因为在开发中该表单确实有效），对于开发，它会生成下面的 post，这似乎与下面的 post 不同测试日志。我应该如何调整测试语法以创建与开发中相同的 post？
Parameters: {"utf8"=>"✓", "authenticity_token"=>"***", "organization"=>{"name"=>"test60", "bag"=>"tes60", "users_attributes"=>{"0"=>{"email"=>"test60@example.com", "username"=>"test60", "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]"}}}, "commit"=>"Register"}
更新： 为了匹配开发日志，我将测试中的 post 行更改为：
post organizations_path, organization: { name: "Abc def 1",
bag: "adef1",
users_attributes: { "0" => {email: "adef1@uniqu.br",
username: "adef1",
password: "foobar",
password_confirmation: "foobar"}} }
end
现在在测试日志中它不再有 IS NULL LIMIT 但它仍然回滚因此测试仍然失败并显示相同的消息：
[1m[35mSQL (0.5ms)[0m INSERT INTO "organizations" ("name", "bag", "created_at", "updated_at") VALUES (, , , ) RETURNING "id" [["name", "Abc def 1"], ["bag", "adef1"], ["created_at", "2015-06-27 19:49:45.430750"], ["updated_at", "2015-06-27 19:49:45.430750"]]
[1m[36mUser Exists (0.4ms)[0m [1mSELECT 1 AS one FROM "users" WHERE LOWER("users"."email") = LOWER('adef1@uniqu.br') LIMIT 1[0m
[1m[35m (0.5ms)[0m SELECT "users"."email" FROM "users" ORDER BY "users"."username" ASC
[1m[36mUser Exists (0.5ms)[0m [1mSELECT 1 AS one FROM "users" WHERE LOWER("users"."username") = LOWER('adef1') LIMIT 1[0m
[1m[35m (0.2ms)[0m ROLLBACK TO SAVEPOINT active_record_1
您的测试代码与您的开发代码不一样。您需要在 users_attributes 数组内添加方括号：
test "valid combined organization user signup" do
get new_path
assert_template 'organizations/new'
assert_difference ['Organization.count', 'User.count'], 1 do
post organizations_path,
organization: { name: "Abc1",
bag: "aef1",
users_attributes: { "0" => { email: "test@test.br",
username: "abc1",
password: "foobar",
password_confirmation: "foobar" } } }
end
end
这就是为什么您的日志说它正在尝试查找 email IS NULL 的用户，因为它无法正确检索 email 属性，所以它只是默认为 NULL 而不是 test@test.br.
编辑： 已更新以匹配工作语法。 OP 还报告说，一旦语法得到修复，User 模型就会出现错误，无法通过 username 上的最小长度验证，他只需在测试数据中使用更长的用户名即可修复该错误。
我已经为写入两个 tables/models 的注册表单编写了集成测试。它失败并显示消息 "Organization.count" didn't change by 1。但是，有没有一种方法可以查看测试失败的错误消息类型（该表单在开发中有效，尽管显示错误消息存在问题，所以我不明白测试失败的原因）。所以我的意思是如果你在服务器上做了同样的事情你会看到错误消息来帮助我找出为什么它没有保存 organization/user.
test "valid combined organization user signup" do
get new_path
assert_template 'organizations/new'
assert_difference ['Organization.count', 'User.count'], 1 do
post organizations_path, organization: { name: "Abc1",
bag: "aef1",
users_attributes: [email: "test@test.br",
username: "abc1",
password: "foobar",
password_confirmation: "foobar"] }
end
end
也许测试日志可以提供帮助？我在这里看到 IS NULL LIMIT 用户电子邮件和用户名。鉴于测试语法，我不明白为什么...
Started POST "/organizations"
Processing by OrganizationsController#create as HTML
Parameters: {"organization"=>{"name"=>"Abc def 1", "bag"=>"adef1", "users_attributes"=>[{"email"=>"adef1@uniqu.br", "username"=>"adef1", "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]"}]}}
[1m[36m (0.2ms)[0m [1mSAVEPOINT active_record_1[0m
[1m[35mOrganization Exists (0.6ms)[0m SELECT 1 AS one FROM "organizations" WHERE LOWER("organizations"."name") = LOWER('Abc def 1') LIMIT 1
[1m[36mOrganization Exists (0.3ms)[0m [1mSELECT 1 AS one FROM "organizations" WHERE LOWER("organizations"."bag") = LOWER('adef1') LIMIT 1[0m
[1m[35mOrganization Exists (0.3ms)[0m SELECT 1 AS one FROM "organizations" WHERE LOWER("organizations"."name") = LOWER('Abc def 1') LIMIT 1
[1m[36mOrganization Exists (0.3ms)[0m [1mSELECT 1 AS one FROM "organizations" WHERE LOWER("organizations"."bag") = LOWER('adef1') LIMIT 1[0m
[1m[35mSQL (0.4ms)[0m INSERT INTO "organizations" ("name", "bag", "created_at", "updated_at") VALUES (, , , ) RETURNING "id" [["name", "Abc def 1"], ["bag", "adef1"], ["created_at", "2015-06-27 16:28:56.179789"], ["updated_at", "2015-06-27 16:28:56.179789"]]
[1m[36mUser Exists (0.6ms)[0m [1mSELECT 1 AS one FROM "users" WHERE "users"."email" IS NULL LIMIT 1[0m
[1m[35m (0.6ms)[0m SELECT "users"."email" FROM "users" ORDER BY "users"."username" ASC
[1m[36mUser Exists (0.2ms)[0m [1mSELECT 1 AS one FROM "users" WHERE "users"."username" IS NULL LIMIT 1[0m
[1m[35m (0.2ms)[0m ROLLBACK TO SAVEPOINT active_record_1
控制器方法post在这里编辑：whosebug.com/q/31072646/4499505（organizations_path指创建方法）
如果我将测试日志与开发日志进行比较（因为在开发中该表单确实有效），对于开发，它会生成下面的 post，这似乎与下面的 post 不同测试日志。我应该如何调整测试语法以创建与开发中相同的 post？
Parameters: {"utf8"=>"✓", "authenticity_token"=>"***", "organization"=>{"name"=>"test60", "bag"=>"tes60", "users_attributes"=>{"0"=>{"email"=>"test60@example.com", "username"=>"test60", "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]"}}}, "commit"=>"Register"}
更新： 为了匹配开发日志，我将测试中的 post 行更改为：
post organizations_path, organization: { name: "Abc def 1",
bag: "adef1",
users_attributes: { "0" => {email: "adef1@uniqu.br",
username: "adef1",
password: "foobar",
password_confirmation: "foobar"}} }
end
现在在测试日志中它不再有 IS NULL LIMIT 但它仍然回滚因此测试仍然失败并显示相同的消息：
[1m[35mSQL (0.5ms)[0m INSERT INTO "organizations" ("name", "bag", "created_at", "updated_at") VALUES (, , , ) RETURNING "id" [["name", "Abc def 1"], ["bag", "adef1"], ["created_at", "2015-06-27 19:49:45.430750"], ["updated_at", "2015-06-27 19:49:45.430750"]]
[1m[36mUser Exists (0.4ms)[0m [1mSELECT 1 AS one FROM "users" WHERE LOWER("users"."email") = LOWER('adef1@uniqu.br') LIMIT 1[0m
[1m[35m (0.5ms)[0m SELECT "users"."email" FROM "users" ORDER BY "users"."username" ASC
[1m[36mUser Exists (0.5ms)[0m [1mSELECT 1 AS one FROM "users" WHERE LOWER("users"."username") = LOWER('adef1') LIMIT 1[0m
[1m[35m (0.2ms)[0m ROLLBACK TO SAVEPOINT active_record_1
您的测试代码与您的开发代码不一样。您需要在 users_attributes 数组内添加方括号：
test "valid combined organization user signup" do
get new_path
assert_template 'organizations/new'
assert_difference ['Organization.count', 'User.count'], 1 do
post organizations_path,
organization: { name: "Abc1",
bag: "aef1",
users_attributes: { "0" => { email: "test@test.br",
username: "abc1",
password: "foobar",
password_confirmation: "foobar" } } }
end
end
这就是为什么您的日志说它正在尝试查找 email IS NULL 的用户，因为它无法正确检索 email 属性，所以它只是默认为 NULL 而不是 test@test.br.
编辑： 已更新以匹配工作语法。 OP 还报告说，一旦语法得到修复，User 模型就会出现错误，无法通过 username 上的最小长度验证，他只需在测试数据中使用更长的用户名即可修复该错误。