应该在 Django 中编写什么样的测试
假设我有一个 Djano 应用程序。用户可以注册、获取激活邮件、激活帐户并登录。登录后，用户可以通过使用管理器处理模型的自定义表单来创建、更新和删除对象。
我应该在这里测试什么 - 我应该使用请求框架发出请求并通过视图和表单测试整个链，还是应该编写单元测试来测试管理器和模型？
在测试整个链时，我发现 URL 配置正确，视图按预期工作，表单正确清理数据，并且还会测试模型和管理器。看起来 Django 测试框架比这种测试更适合单元测试。 （这是应该用 Twill 和 Selenium 进行测试的东西吗？）
在编写单元测试时，我会测试 Manger 和 Models，但是 URL 和 Forms 并没有真正发挥作用，不是吗？
这是一个非常基本的问题，但我想弄清楚一些基本原理。
谢谢大家。
Let's says I have a Djano app. Users can sign up, get a activation mail, activate their accounts and log in. After logging in, users can can create, update and delete objects rhough a custom Form which uses the Manager to handle the Model.
What should I be testing here — should I use the request framework to make requests and test the whole chain via the Views and Forms or should I be writing unit tests to test the Manager and the Model?
When testing the whole chain, I get to see that the URLs are configured properly, the Views work as expecvted, the Form cleans the data properly and it would also test the Models and Managers. It seems that the Django test framework is more geared toward unit-testing than this kind of test. (Is this something that should be tested with Twill and Selenium?)
When writing unit tests, I would get to test the Manger and the Models but the URLs and the Forms don't really come into play, do they?!
A really basic question but I'd like to get some of the fundamentals correct.
Thank you everyone.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，Django 单元测试，使用客户端功能，能够测试你的路由和表单是否正确。
如果您想要从外部进行全面的行为驱动测试，您可以使用像 Zombie 这样的 BDD 框架。
至于你需要哪些测试，Django 作者 Jacob Kaplan-Moss 简洁地回答了这个问题：“全部”。
我的一般测试理念是一直工作到愚蠢的事情发生，然后编写测试以确保愚蠢的事情不再发生。
Yes, Django unit tests, using the Client feature, are capable of testing whether or not your routes and forms are correct.
If you want full-blown behavior-driven testing from the outside, you can used a BDD framework like Zombie.
As for which tests you need, Django author Jacob Kaplan-Moss answered the question succinctly: "All of them."
My general testing philosophy is to work until something stupid happens, then write a test to make sure that stupid thing never happens again.