如何针对 404 - Not Found 进行单元测试或集成测试？
我的团队正在使用 S#arp 架构框架在 ASP.Net MVC 2 中编写内容管理的 Web 托管应用程序。我使用 SpecFlow 和 WatiN 进行集成测试，使用 NUnit 进行单元测试。
我有一个自定义控制器工厂，它根据 URL 和站点在数据库中定位页面，然后加载正确的控制器和操作。当在数据库中找不到页面（或站点）时，它还会加载错误控制器。
我想编写一个单元测试或集成测试来验证当 URL 无效时 404 页面是否正确显示。 WatiN 无法检查响应标头，因此无法准确确保实际的 404 页面已加载。这可能会消除集成测试作为解决方案。
我是 TDD 和 BDD 的新手，所以我可能会遗漏一些明显的东西。另外，我正在对这个项目进行改造测试，这使得它变得更加困难。
提前致谢。
My team is writing a content-managed web-hosting application in ASP.Net MVC 2 with the S#arp Architecture framework. I'm using SpecFlow and WatiN for integration testing, and NUnit for unit testing.
I have a custom controller factory that locates a page in the database based on the URL and site, and then loads the proper controller and action. It also loads an error controller when the page (or site) is not found in the database.
I want to write either a unit test or integration test that validates a 404 page is properly displayed when the URL is invalid. WatiN cannot check the response header, so it cannot accurately ensure an actual 404 page was loaded. This may eliminate an integration test as the solution.
I'm new to TDD and BDD, so I may be missing something obvious. Also, I am retro-fitting tests into this project, which makes it that much more difficult.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常我们在编写BDD场景时，都是从用户的角度来编写的。
如果用户是普通人，他们可能不太关心标头是否是真正的 404。他们更喜欢页面给他们提供清晰且有用的消息。编写场景以检查是否有清晰且有用的消息。
BDD 并不是真正的测试。这是关于让你发现其他你没有想到的事情的对话，并对应该发生的事情形成共同的理解。例如，当普通用户尝试访问管理页面时会发生什么？他们是否应该得到“访问被拒绝”或根本不知道该页面在那里？如果删除页面怎么办？这些讨论比试图确定一切更有用。
如果您的 404 与发送给用户的特定消息相关联，那么您可以简单地对适当的响应匹配进行单元测试。这将大大减少将来在消息中意外发送错误代码的可能性，并且您可以专注于真正的好处。
Normally when we write BDD scenarios, we write them from the user's perspective.
If the user is an ordinary person, they probably don't care too much about whether the header is a genuine 404. They'd prefer a page giving them a clear and useful message. Write the scenario to check for the clear and useful message.
BDD isn't really about testing. It's about the conversations which let you discover other things you haven't thought of, and developing a common understanding of what should happen. For instance, what happens when an ordinary user tries to access an admin page? Should they get "access denied" or simply not know that the page is there? What if a page is deleted? Those discussions are more useful than trying to pin everything down.
If your 404 is associated with a particular message to the user, then you can simply unit-test that the appropriate response matches. That will drastically reduce the chances of accidentally sending the wrong code with a message in the future, and you can focus on the real benefit.