何时/如何对CRUD应用程序进行单元测试？

Question

我最近听到很多关于单元测试的消息.

我想要了解的是,一个/应该如何进行单元测试一个肮脏的商业应用程序？(基本上是一个将数据写入数据库/从数据库中读取数据的应用程序).

单元测试是否值得在那个场景中进行测试,或者您是否经常对更复杂的事情进行单元测试？

谢谢

Answer 1

单元测试是关于测试离散的代码单元 - 单一方法,不再是.

你进入CRUD的那一刻,你正在谈论测试网络,IO,数据库和其他东西 - 这超出了单元测试的范围.在这种情况下,这称为集成测试(您正在测试代码如何与其他代码/系统集成).

在任何软件项目,CRUD应用程序中是否存在两种类型的测试(以及其他类型 - 回归,性能等...).

Answer 2

如果您的所有应用程序都是CRUD,那么单元测试没有意义.现在,如果存在任何类型的业务逻辑操纵值,因为它们来自数据库或在它们进入之前验证它们,是的,构建单元测试是个好主意.测试CRUD部分不属于单元测试IMO.

Answer 3

粗鲁的应用程序很少保持粗鲁的状态。他们最终成长为包括业务对象层。

所以，是的，我将进行单元测试。即使是基本的粗鲁应用程序也应分为交互层，数据访问层和难以置信的简单UI（请注意，所有UI状态都应保留在交互层中）。最终，您可能会在交互层和数据访问层之间获得一个业务对象层。

Answer 4

我知道每个人都在不断讨论如何首先测试所有设计，但是我倾向于坚持对更复杂的事物进行单元测试。

我的经验法则是针对我实际上希望因可靠性而破坏的事物或不立即发现的事物建立自动化测试。最重要的是，我希望它能够测试无法/不会彻底测试自己的事情。

例如，“使用47个不同的变量来计算一些大的复杂事物”模块应该具有一堆测试，可以很好地覆盖代码并覆盖所有可能的代码路径，但是实际上将结果保存回数据库的代码却没有必然需要测试，尤其是在进行简单的CRUD工作时。

另外，我喜欢使用自动化的UI测试（使用WatiN或类似工具）来为我的网站构建回归测试，这样，当我更改某些核心组件时，我可以运行健全性检查以确保我不会感到惊讶网站的一角。

最后，一切都与投资回报率有关。您要花多少时间，您要花多少时间。如果您的单元测试在您的CRUDy商业应用程序的某些哑数据访问层上接近100％的代码覆盖率，那么您在浪费时间和雇主的金钱，简单明了。但是，如果您要建造火箭飞船或医疗设备，或者您是一家没有质量检查部门资源的两主体商店，那么大量的单元测试可以为您节省大量时间，金钱和/或生命。