护法、金刚、散人、etc、etc： 讨论一下【Unit Test】VS 【Integration Test】

梦呓人

看到一篇文章，谈到了unit test的局限性，和我的想法差不多
http://arialdomartini.wordpress. ... ts-why-i-love-them/



在时间资源有限的情况下，是否应该更重视integration test？



大家讨论讨论

梦呓人

我的老板是unit test忠实的拥护者，他的理论是一个中型项目至少要有500个unit tests.我认为这是在浪费时间和公司的钱。


下午准备去拍桌子，现在来这里拿点弹药

workflow

integration test和unit test干的不是一个事吧？

pengruijun

这种事情，仁者见仁， 就跟讨论软件开发流程一样。 谁也争不过谁

梦呓人

我的理解是：

Unit Test 写的时间短，因为不能涉及数据库操作、文件系统读写、web service的访问，所以一切都必须mock。所以即使所有的unit tests都绿灯通过了，也不意味着软件可以交货或者deploy了，甚至还差的很远可能。有时候劣质的unit test实际上在自欺欺人。



Integration Test是实打实的运行环境测试，它能通过，那些unit test的小部分也就肯定是pass的。而且它反而省去了烦琐的mock。譬如我有一个程序是：连到到某个sql server + 运行一个sql script +检查数据库是否被成功创建 + log到文件， 用unit test不但局限性很大而且不能证明任何成功，直接上intergration test简单而且可以最大程度保证程序是work的。



继续继续

psaux

理论上都是必须要做的东西，只是现实中都要向deadline和budget妥协。

atransformer

mxgong

我们公司做UNIT TEST 的。

商务车

做road test的飘过.........

yangwulong1978

功用不同，ＵＮＩＴＴＥＳＴ　是小的模块测试，你小模块做完后集成到系统里后做的测试叫集成测试，，
集成测试也不是实打实的真实环境测试，只是你的开发，测试机器测试，，
最后是FINALTEST 是要在实际的用户机器上测试的。。。。。。

其实这些都是虚的，，，，，根据每个公司的预算来定的，，，，，，



不过刚开始做UNIT TEST 的多对以后有好处，
这些跟写TEST CASE的人的水平有关，，，，

[ 本帖最后由 yangwulong1978 于 2012-2-7 13:09 编辑 ]

rationalrup

不做string test的吗？String Test 就要写Mock, Unit Test可以重用。 String Test -> Unit/System Test -> Integration Test, User Acceptance Test, Product Verification Test, Stress and Volumn Test, 从来是一个都少不了，都要SignOff的。

典

原帖由 pengruijun 于 2012-2-7 11:28 发表
这种事情，仁者见仁， 就跟讨论软件开发流程一样。 谁也争不过谁

老大说了算，老大说要做就做，老大说不做就不做。
老大说没有意见，随便，那就看自己心情，做一小部分验证一些复杂算法？

huazhb

集成测试，很多代码的路径和边界条件都是测不出的。所以还是需要Unit Test的。 但是界面的逻辑靠Unit Test很困难或者很麻烦， 就只能靠集成测试了

workflow

完全干的事情不一样，不知道你做的项目规模有多大，稍微有点规模的项目，这两个都非常重要。不做或少做Unit Test 怎么能保证Integration Test能顺利进行？你们的项目可能是在一个封闭的环境里，如果涉及到其他产品的EAI，跳过Unit Test直接Integration Test简直是不可能的。

不过话说回来，还是老板说了算，小项目，没测试的都很多

findcaiyzh

我觉得Unit Test还是为了修改。如果项目需求很明确，以后不会升级，一年半载后bug也不用修改了，这样不用unit test.

否则，过上半年，需求变动，升级，或者修bug，很容易引起衰退。尤其是有点复杂的项目。

其实我们也不写unit test。现在我正在为一个同事2年前的项目的遗留bug头疼呢，虽然定位到bug所在，但是有点不敢下手啊。

karaoke_oz

钱多，时间多，什么都可以作，钱少，时间少，那就老板说的算了。

无视

那篇文章的作者肯定是没做过几天TDD，就乱发感慨，注重integration test不意味贬低unit test，作者显然扭曲了fake在unit test中的意义.

unit test它是在测试code本身逻辑上的健壮性，他的前提就是假设dependency是正常工作的，不要这一点上argue，否则会被认为无理取闹。

integration test当然重要，但目的不同，它的工作不是测试code的健壮性，而是各个components的协作性，我们用selenium作end-to-end(db-ui)test。

Unit test有两点经常被人们或略甚至不提,不过在我们的开发过程中是每天都会发生的

1.它是一种机制来enforce你的思路，如果后来别人修改你的code，你原来的unit test会报错，让后来修改的人有足够的重视，如果这点很难接受，就想像database的data integration/constraints,类似的道理，unit test是logic的constraint。

2.unit test强制developer从high level上架构/重构自己的逻辑和input/output,这点对自我fix bug非常有效。

开发阶段的unit test和维护阶段的写法风格绝对不同，但基本要求是任何逻辑的改变，都应该有相应的unit test来enforce你的改变，这是我们code review的标准，否则不能checkin，除非是UI的修改。

Unit test才只是开始，围绕unit test，有很多的best practice/frameworks, unit coverage只是management方面的指标，很stupid，我们基本忽略，我们注重solid的unit test.

很多community不提倡的private/protect/internal的class/member，我们都尽可能用reflection去测，可能有点偏激了，但object incapsulation的确让有很多framework不能正常工作，我们的努力就是为了克服这一点，既能做很好的oo design，又能完全作unit test.

我们的integration test由众多acceptance test组成，80%以上都在verify page上的element的值或者是存在性，它本身是piple line,每当code checkin，integration test都会被触发，一旦break，就会作为top priority task，dev需要去fix，一般情况下break unit test可以避免，但break integration可能就无法避免。

[ 本帖最后由 无视 于 2012-2-7 16:08 编辑 ]

o2h2o

无兄的发言一般要看三遍, 信息量太大

梦呓人

原帖由 无视 于 2012-2-7 15:34 发表
那篇文章的作者肯定是没做过几天TDD，就乱发感慨，注重integration test不意味贬低unit test，作者显然扭曲了fake在unit test中的意义.

unit test它是在测试code本身逻辑上的健壮性，他的前提就是假设dependency是正常工作的，不要这一点上argue，否则会被认为无理取闹。

integration test当然重要，但目的不同，它的工作不是测试code的健壮性，而是各个components的协作性，我们用selenium作end-to-end(db-ui)test。

Unit test有两点经常被人们或略甚至不提,不过在我们的开发过程中是每天都会发生的

1.它是一种机制来enforce你的思路，如果后来别人修改你的code，你原来的unit test会报错，让后来修改的人有足够的重视，如果这点很难接受，就想像database的data integration/constraints,类似的道理，unit test是logic的constraint。

2.unit test强制developer从high level上架构/重构自己的逻辑和input/output,这点对自我fix bug非常有效。

开发阶段的unit test和维护阶段的写法风格绝对不同，但基本要求是任何逻辑的改变，都应该有相应的unit test来enforce你的改变，这是我们code review的标准，否则不能checkin，除非是UI的修改。

Unit test才只是开始，围绕unit test，有很多的best practice/frameworks, unit coverage只是management方面的指标，很stupid，我们基本忽略，我们注重solid的unit test.

很多community不提倡的private/protect/internal的class/member，我们都尽可能用reflection去测，可能有点偏激了，但object incapsulation的确让有很多framework不能正常工作，我们的努力就是为了克服这一点，既能做很好的oo design，又能完全作unit test.

我们的integration test由众多acceptance test组成，80%以上都在verify page上的element的值或者是存在性，它本身是piple line,每当code checkin，integration test都会被触发，一旦break，就会作为top priority task，dev需要去fix，一般情况下break unit test可以避免，但break integration可能就无法避免。

我的偶像又多了一个！！!

atransformer

yangwulong1978

其实个人觉得测试方法不太重要，还是个人的专业能力，和TESTING SENSE 很重要。。。

捉五龙

原帖由 atransformer 于 2012-2-7 17:19 发表

左胸比右胸大？！

xiaotuanyuan

哎，不得不感叹一下挨踢人的语言能力。
是中文退步了，还是英文进步了？

gooderic1977

原帖由 梦呓人 于 2012-2-7 12:45 发表
我的理解是：

Unit Test 写的时间短，因为不能涉及数据库操作、文件系统读写、web service的访问，所以一切都必须mock。所以即使所有的unit tests都绿灯通过了，也不意味着软件可以交货或者deploy了，甚至还差的很远可能。有 ...

Unit Test不能涉及数据库操作？我突兀了。。。。
难道针对DAL的unit test不应该读写数据库？Service Layer以上的Unit Test我会用Mock，但是DAL这一层的unit test我不用mock的。

一般在DAL unit test,里我会在Setup生成测试数据，并在Teardown删除测试数据，这种方法有问题吗？请大牛们指正一下。

梦呓人

你是怎么访问数据库的？

nhibernate？

梦呓人

原帖由 atransformer 于 2012-2-7 17:19 发表

无视就是乱码兄？？？？？？

gooderic1977

原帖由 梦呓人 于 2012-2-8 14:34 发表
你是怎么访问数据库的？

nhibernate？

我们不用dynamic sqlscript base的ORM。公司的自己写得mapper,通过SPROC来读些数据库的。

atransformer

原帖由 梦呓人 于 2012-2-8 14:35 发表




无视就是乱码兄？？？？？？

打死我也不说，是。打死我也不说，是。打死我也不说，是。打死我也不说，是。打死我也不说，是。打死我也不说，是。打死我也不说，是。

atransformer

原帖由 捉五龙 于 2012-2-8 11:28 发表


左胸比右胸大？！

及之而后知，摸之而后坚

无视

原帖由 gooderic1977 于 2012-2-8 14:30 发表


Unit Test不能涉及数据库操作？我突兀了。。。。
难道针对DAL的unit test不应该读写数据库？Service Layer以上的Unit Test我会用Mock，但是DAL这一层的unit test我不用mock的。

一般在DAL unit test,里我会在Setup生成测试数据，并在Teardown删除测试数据，这种方法有问题吗？请大牛们指正一下。

DAL的unit test不应该读写database.贴个例子

[TestClass]
    public class ConfirmBidDataProviderTests
    {
        [TestMethod]
        public void ConfirmBidDataProvider_GetData_ReturnsImageTypeWhenReturnsValue()
        {
            //Arrange
            const int lotId = 1;
            const ImageType expectedImageType = ImageType.Shared;
            var dbConnection = MockDbConnection(lotId, expectedImageType);
            var configurationService = MockRepository.GenerateStub<IConfigurationService>();

            //Act
            var dataProvider = new ConfirmBidDataProvider(dbConnection, configurationService);
            var data = dataProvider.GetData(lotId,new Guid());

            //Assert
            Assert.AreEqual(expectedImageType, data.ImageType);
        }

        MockDb MockDbConnection(int lotId, ImageType? imageType)
        {
            return new MockDb (new[]
                               {
                                   new CommandMockResult(
                                       "usp_ConfirmBid_GetData",
                                       CommandType.StoredProcedure,
                                       new Dictionary<string, IComparable>{ { "@LotId", lotId } },
                                       new[]
                                       {
                                           new Dictionary<string, object>
                                           {
                                               {"ImageType", imageType.HasValue ? PersistedStringValueAttribute.GetValue(imageType.Value) : null },
                                               {"ImageId", 1244 },
                                               {"SaleId", 123 },
                                               {"SaleDisplayName", "salename" },
                                               {"SaleCategoryName", "salecategoryname" },
                                           }
                                       }
                                       )
                               }
                );
        }
    }