“零迭代” - 简单联系表功能中的端到端验收测试
我最近正在阅读《开发面向对象的软件，以测试为指导》。 本书的作者建议始终在开始开发功能时进行端到端验收测试（在开始 TDD 周期之前），以免失去进度跟踪并确保您仍然处于领先地位单元测试时的同一页面。
好的，所以我开始用 python+django 编写一个非常简单的应用程序，只是为了尝试这种方法。我希望用户能够通过联系表单提出问题，然后问题应该存储在数据库中，完成后应该发送一个信号来通知邮件程序，邮件程序将发送后续消息。
问题是 - 在这种情况下，您将如何进行第一个端到端测试？您是否在第一个测试中包含了所有可能性，或者也许我误解了整个技术。
任何例子都将受到欢迎。
I was reading "Growing Object-Oriented Software, Guided by Tests" lately.
Authors of this book sugested to always start developing a feature with an end-to-end acceptance test (before starting TDD cycle) to not loose a track of progress and to make sure that you're still on the same page while unit-testing.
Ok, so I've start writing a veeeery simple application in python+django just to try this approach out. I want User to be able to ask a question via contact-form, the question should be then stored in a db, and a signal after completion should be send to notify mailer which will send follow-up message.
Question is - how you'd approach this first end-to-end test in this case? Do you have contain all possibilities in this first test, or maybe I'm misunderstanding this whole technique.
Any examples would be most welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您根本不必在验收测试中包含所有可能性 - 您仍然需要编写单元测试。所以我想说，一个单一的测试“用户可以填写表单，保存并加载它”就足以开始。然后，如果您认为系统的某个特定方面足够重要以至于需要验收测试，则可以添加更多测试。不要担心在这里处理所有可能性，您仍然会编写大量的单元测试，在其中测试所有内容！
最简单的开始方法是与代码并行地扩展验收测试：因此从测试用户可以输入数据开始，实施它直到它停止失败，然后向测试添加用户必须加载此数据的条件在你开始编写生产代码之前，需要一段时间来实现验收测试的初始基础设施，但无论如何你都无法逃避它，而且预先进行测试有很多好处。
You don't have to contain all possibilities in acceptance tests at all - you will still write unit tests. So I would say that a single tests "user can fill in the form, save it and load it back" is enough to start with. Then you can add more tests if you think that a particular aspect of your system is important enough that it needs an acceptance tests. Don't worry about handling all possibilities here, you will still write tons of unit tests where you will test everything!
The easiest way to start is to grow your acceptance test in parallel with the code: so start with testing that the user can input data, implement it until it stops failing, then add to the test the condition that the user has to load this data back etc. It will take a while to implement the initial infrastructure for the acceptance test, before you even start writing production code, but you can't escape from it anyway, and there are various benefits to have tests upfront.
该用例导致多个测试用例（每个测试用例都测试专用的可能执行路径）。
当编写测试集中于一个可能的结果时，一段时间后测试套件就会增长。第一个测试还为您提供安全网作为回归测试，以免破坏您已经成功实施的任何内容。
我的第一个测试是：
填写其余部分；）取决于更详细的要求.. 。
请记住尽可能简单地实现上述内容 当所有测试都到位后，进行无情的重构，使“内部质量”变得良好。
This use-case leads to several test-cases (every tests a dedicated possible path of execution).
When writing tests focus on one possible outcome, after a while test-suite grows. The first tests then also give you safety net as regression tests to not break anything which you already implemented successfully.
My first tests would be:
Fill out the rest ;) Depends on the more detailed requirements...
Remember to implement above as simple as possible. When all tests are in place, refactor ruthlessly to make "internal quality" nice.