这个问题很可能是基于意见的。但我确信，有确凿论据支持的观点将为明智的决策铺平道路。
我确实喜欢使用 Autofixture 生成数据库状态。
我真诚地讨厌编写 SQL 脚本，然后编写与该脚本的假设“神奇”相关的期望，因为我不喜欢知识/逻辑跨层/技术传播。
我讨厌当某些没有默认值的列添加到表中时测试会失败，并且我们必须手动编辑所有失败的脚本，即使对于根本不使用该列的测试也是如此。
我喜欢可以轻松地从数据库状态中得出期望，或者了解当数据库模式和类发生变化时编译如何失败。并且仅在接触更改列的测试中才会出现问题。
我的同事半信半疑地接受了最后的论点，但仍然坚持认为调试的简便性比测试的脆弱性更重要。他们认为随机生成的数据很难调试和读取，他们坚持认为理解 4 个静态/稳定 sql 屏幕比查看生成某些对象集合的代码然后设置“影响测试的逻辑”属性值要容易得多。
他们的观点是：
当我明确指出实体 A 必须与实体 B 相关并且
后来我看到 A 与 C 相关，我明白导致错误的原因。
但很难将无意义的对象互连起来：B 和 C 变成
人类无法区分。并将身份赋予
实体我们必须设置其他不影响逻辑的属性
正在接受测试。
我提出了一些妥协。
通常有某种“名称”属性，我们可以手动设置对象的“标签”。
他们不愿意接受这个建议，我就想问：
好吧，伙计们，让我们暂时忘记 Autofixture 的随机性，假装
我们只是将数据库状态表示为 POCO 对象并在之前将它们持久化
调用被测试的方法。我们失去了构造逻辑的独立性，但我们仍然可以明确地设定来自国家的期望。
事实上，我对大家的反应感到惊讶：
要调试这些，我需要打开 Visual Studio 并执行
数据持久化后暂停。但是，我们不承诺交易
- 测试后所有更改都会回滚。因此，我需要从 SQL Management Studio 中读取未提交的数据。有这么多
仅用于调试存储过程的动作。我更愿意写
sql 脚本而不是 POCOS。
所以现在它变成了关于个人喜好和品味的讨论。另一方面，很容易成为一个有偏见的热情采摘者和松散的客观性。
这就是为什么我想听听社区的一些想法和论点。
None
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
