单元测试 – 集成与单元测试

我正在用Grails开发.由于框架将引导数据和完全刷新的 spring上下文,我发现我为服务编写了很多集成测试.让我重新说一下:我发现我没有为服务编写单元测试,只编写集成测试.这是一个坏主意吗?我看到的唯一缺点是我的测试需要更长的时间才能运行.

我在控制器上使用单元测试,就像在控制器中我正在测试各种应用程序流,结果类型,重定向逻辑等.但我编写的大多数测试都是集成测试.这似乎是传统J2EE测试的一个突破,其中大多数是单元测试.

编辑 – 要清楚,我不是在编写集成测试,因为代码是如此复杂,只有集成测试才能做到.我正在编写集成测试,因为它更容易一起测试所有内容,因为框架为您提供了很多.我会模拟某些事情,比如服务与acegi authenticationService协作,我嘲笑它.我也可以在任何时候与web服务进行交互时进行模拟,因为你必须在没有特殊设置的情况下运行测试.

我清楚地看到了更多功能测试和更少单元测试的趋势,特别是对于逻辑低的高连接组件.如果我在特定的类中实现一个复杂的算法,我通常会为它编写单元测试,但如果复杂性是由于与其他组件的集成(这种情况经常发生),单元测试不值得麻烦.

相关文章

适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法...
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题...
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结...
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容...