c# – 用于排列单元测试的序列化对象图

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了c# – 用于排列单元测试的序列化对象图，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3408字，纯文字阅读大概需要5分钟。

内容图文

我有一个应用程序,其中问题域由高度相关的域对象表示.我已经将域拆分为一些聚合根对象,这有助于对模型施加顺序,但是为单元测试安排前提条件非常困难,因为创建这些聚合根的实例需要创建大量引用的支持对象.

我想编写可重复的,独立的单元测试来运行应用程序而不需要外部依赖(理想情况下不需要编写大量代码).

我认为这些是我的选择.任何偏好或其他建议？

>编写构建脚本,设置项目数据库并将已知数据插入其中,然后执行单元测试.这是我最不喜欢的选项,因为它引入了外部依赖(因此不是真正的单元测试)以及更多潜在的失败.它也不会隔离正在测试的业务功能,因为故障可能位于数据访问代码中.
>创建可重用的工厂,创建具有已知状态的域对象,运行单元测试.这样可以很好地工作,但意味着需要编写大量样板代码,因此在模型更改时会有很多变化.
>(当前方法)将聚合根对象的二进制序列化创建为使用测试项目签入的文件.单元测试将它们反序列化以进行测试.这样做的缺点是,如果基础类型更改反序列化将失败,并且必须重新创建所有序列化文件.
>吸取它并编写一个自定义序列化程序,将图形序列化为XML文件,这些文件可以检入解决方案并在测试时反序列化.与2类似,这意味着需要编写大量的前期样板代码,但维护更容易,因为如果模型更改,可以使用文本编辑器轻松编辑序列化状态.
> UR干得好.您的域对象如此高度引用这一事实是主要问题.简化它.

谢谢！

解决方法:

Write build scripts that setup the project database and INSERT known data into it, against which unit tests are executed. This is my least favorite option as it introduces an external dependency (and therefore isn’t a true unit test) as well as many more potential failures. It also doesn’t isolate the business function being tested because the fault could lie within the data access code.

“整合而不是单位”是一个小问题(特别是与“测试或不测试”相比),我不担心.这种方法还有其他更严重的问题：

>编写脚本.你最有可能最终手工编写SQL,这需要很多纪律,特别是当模型很复杂时.错别键是很痛苦的,调试/检测问题很困难,你也需要考虑IDE /工具.
>当您的模型发生变化时,您将修复那些引发相同问题的SQL脚本 – 拼写错误,难以发现错误等等,缺乏IDE支持.

总的来说,这种方法在可维护性方面是昂贵的.

Create re-usable factories that create domain objects with a known state, against which unit tests are run. This will work well, but means lots of boilerplate code to be written, and therefore lots to change when/if the model changes.

体面的方法,您应该调查使这个过程更容易的库(提示：AutoFixture,NBuilder).

(Current method) Create binary serializations of my aggregate root objects into files that are checked in with the test project. The unit tests deserialize them for their tests. The downside to this is that if the underlying type changes deserialization will fail and all the serialized files have to be re-created.

与build-scripts相同的问题之一 – 更改将是昂贵的.

Suck it up and write a custom serializer that serializes the graphs to XML files that can be checked in to the solution and deserialized at test time. Like 2, this means alot of up-front boilerplate code to be written, but maintenance is easier as the serialized state can be edited easily with a text editor if the model changes.

这与第二个解决方案基本上是相同的解决方案,但在中间使用XML作为man.为何添加额外的图层？

UR DOIN IT RONG. The fact that your domain objects are so highly referential is the main problem. Simplify it.

相当不太可能根据他们的自然领域对象,他们往往是复杂的.

结论

这种问题没有快速和肮脏的解决方法.复杂域意味着必须在某些时候完成一些额外的工作.基于序列化的解决方案(1,3,4),即使现在看起来有些简单,但只会将所述额外工作推迟到引入更改的那一刻.几乎在每种情况下,我都会有更好的灵活性和准备好进行更改(只有第二种解决方案提供 – 如果正确完成).

内容总结

以上是互联网集市为您收集整理的c# – 用于排列单元测试的序列化对象图全部内容，希望文章能够帮你解决c# – 用于排列单元测试的序列化对象图所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端