如何避免集成测试中的业务逻辑重复
我有一个返回产品更改历史记录的 Web 服务方法，它的签名如下所示：
List<MyProduct> GetProductHistory(int iProductId);
我想为此方法创建一个集成测试。为此，我需要在数据库中创建一些数据。在这里，我可以创建一个函数，在数据库中写入一些“硬编码”记录，以模拟产品更改历史记录。
我还需要测试其他函数（int GetProductAverageValue(int iProductId)），它应该使用产品历史信息进行一些数据处理。为了测试这个函数，我需要几组记录（很少不同的历史类型）。在这里我有几个选择：
- 创建一些不同的硬编码数据集（每个测试用例）（那里有很多数据，所以这些数据集有点可怕）；
- 在我的集成测试中创建一些功能，这些功能将为产品创建所需的历史记录...
第一个选项非常巨大，第二个选项 - 导致集成测试层上的业务逻辑重复...
请告知。有任何想法欢迎...
I have one web service method that returns product changes history, it signature looks like this:
List<MyProduct> GetProductHistory(int iProductId);
I would like to create an INTEGRATION test for this method. For that I need to create some data in DB. Here I can create a function that writes some 'hard-coded' records in DB that will simulate product changes history.
I also need to test other function (int GetProductAverageValue(int iProductId)) which should do some data processing using product history information. In order to test this function I need to have few sets of records (few different history types). And here I have few choices:
- Create a few different hard-coded sets of data (each per test case) (there are a lot of data there, so these sets are a little bit scary);
- Create some functionality inside of my integration tests that will create required history for product...
1st option is scary huge, 2nd - leads to duplication of business logic on the Integration Tests layer...
Please advise. Any thoughts are welcome...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不太明白这里的困难是什么。也许你可以澄清为什么这很可怕？
当完全测试某些代码所需的测试用例数量太大时（对于实际程序来说总是），请使用等价分区 选择较少数量的测试用例，但仍能彻底测试代码。
您已经明确表示这是为了集成测试。您已经进行了彻底的单元测试吗？如果没有，请先创建它们。那么集成测试就不再需要测试业务逻辑了；他们只需要测试组件是否已正确粘合在一起。这不需要大量的测试用例。如果是这样，请考虑重新设计您的代码以引入您需要的中间级别的程序集（外观）无需数据库即可测试。
I don't quite understand what the difficulty is here. Perhaps you can clarify why this is scary?
When the number of test cases necessary to test some code completely is too large (which is always the case for real programs), use equivalence partitioning to select a smaller number of test cases that nevertheless thoroughly test the code.
You have specifically said this is for integration testing. Do you already have thorough unit tests? If not, create those first. Then the integration tests no longer need to test business logic; they only need to test that the components have been glued together correctly. That should not require a huge number of test cases. If it does, consider redesigning your code to introduce an intermediate level of assembly (a facade) that you can test without the database.
这是我今天的第二个问题......在完成问题编写后我自己找到了解决方案。
为了创建“一组良好的产品更改历史记录”，我需要使用实际更改产品的服务方法。简单快捷:)
PS无论如何，欢迎任何意见和建议。
Here is my 2nd question today... in which I found solution myself when completed question writing.
To create 'good set of product changes history' I need to use service methods that actually change products. Easy and quick :)
P.S. anyway, any comments and suggestions are welcome.