Web 应用程序：验收测试：测试和测试隔离的初始状态？
问候， 我目前正在探索一些极限编程，并尝试尽可能地坚持下去。这意味着，一旦开始迭代（当然是在计划发布之后），我将需要将我的（到目前为止，出乎意料的厚厚的一堆）用户故事转变为验收测试。
我并不完全确定我将使用的实现语言，但是，我确信这将是一个带有数据库后端、由网络服务器提供服务的动态 Web 应用程序。现在，我计划在具有本地测试环境的本地计算机上开发第一个版本，因此可以假设验收测试不关心安全性（因此，我可以授予验收测试对测试数据库的根访问权限）例如，涉及）。我仍然有点不确定要使用的验收测试框架，但是，由于这将是一个 Web 应用程序，我想我将使用 Selenium RC 来编写测试并运行它们（我提到这一点是为了防止有人能够向我指出更好的东西:)）。
然而，仍然存在一个黑暗区域：我还没有这个应用程序的数据，因为我正在实现一个新的、全新的应用程序。因此，我无法获取当前生产数据库的快照来获取测试数据库，此外，应用程序是有状态的（任何具有数据库后端的 Web 应用程序都是有状态的），因此将使用单个数据库进行所有验收测试导致测试隔离方面出现丑陋的问题（至少对于单元测试来说，这可能会带来很大的乐趣和很多白发）。
那么，我该如何解决这个问题呢？我是否创建人工测试数据库（并在数据库模式更改时维护它们）并编写验收测试，以便每个验收测试在运行测试之前将适当的数据库状态加载到测试数据库中？ （当运行大量重音测试时，加载十几条记录一百次会有多快或多慢？）我应该创建一个示例数据库，为所有测试加载它并希望得到最好的结果吗？我应该在验收测试中重新创建我一直需要的测试数据吗？或者说，人们如何做到这一点？
Greetings,
I am currently exploring some extreme programming and try to stick as much to it as possible. This means, I will need to turn my (by now, unexpectedly thick stack of) user stories into acceptance tests once I begin an iteration (after planning the release, of course).
I am not entirely sure about the implementation language I am going to use, however, I am sure that this is going to be a dynamic web application with a database backend, served by a webserver. Right now, I plan to develop the first release on a local machine with a local testing environment, so it is possible to assume that security is no concern on the acceptance tests (so, I can give the acceptance tests root access to the testing database involved, for example). I am still a bit unsure about the acceptance test framework to use, however, since this is going to be a web application, I think I will use Selenium RC in order to write the tests and run them (I mention this in case someone is able to point me to something better :) ).
However, there still is a dark area left: I do not have data for this application yet, because I am implementing a new, fresh application. Thus, I cannot grab a snapshot of the current production database in order to grab a test database, and additionally, the application is stateful (as any web application with a database backend is), so using a single database for all acceptance tests is going to cause ugly problems with regard to test isolation (and at least for unit tests, that reads as "This can result in great fun and lots of gray hair").
So, how to I solve this problem? Do I create artificial testing databases (and maintain them whenever the database schema changes) and write the acceptance tests such that each acceptance test loads the appropiate database state into the testing database before running the test? (How fast or slow will it be to load a dozen records a hundred times, when a lot of accentance tests run?) Should I create a single example database, load this for all tests and hope for the best? Should I recreate the test data I need all the time in the acceptance tests? Or, how do people do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据进一步的研究，执行此操作的正确方法是使用适当的设置方法使数据库进入定义的状态。这实际上涉及删除表中的所有现有数据，向表中添加特定的测试数据集，然后针对该数据运行测试。之后，teardown 方法会清除对表所做的所有操作（setUp 删除所有内容，或者teardown 再次删除所有内容）。有像 dbUnit 这样的工具可以简化这个过程。这会导致测试速度有所降低，但是，它建立了测试的完全隔离，这是一件好事，因为这样，绿色仅仅意味着绿色，红色仅仅意味着红色，而不是“考虑到当前的测试执行顺序，这有效” ”。
除此之外，速度问题对我来说可能不太重要，因为我可以在为单个用户故事开发代码期间专注于少量测试，并让我的 CI 服务器运行所有测试（这会花费更多时间）当我认为我已经完成时的背景。
According to further research, the proper way to do this is to bring the database into a defined state using the appropiate setUp-methods. This porentially involves deleting all existing data in the tables, adding a certain test set of data to the table and then running the test on exaclty this data. Afterwards, the teardown-method clears up whatever was done to the tables (either setUp drops everything, or teardown drops everything again). There are tools like dbUnit to simplify this process. This results in some reduction of the testing speed, however, it establishes total isolation of tests, which is a good thing, because then, green simply means green and red simply means red and not "Given the current order of test execution, this works".
Besides that, the speed issue will probably be less significant for me, as I can focus on a small amount of tests during developing code for a single user story and have my CI-server run all the tests (which then takes more time) in the background when I think I am done.