[CPyUG:102055] 吹起单元测试的号角

[pyleaf]

有点标题党的嫌疑，哈哈~~
不知大家在实际工作中是怎样规划、设计、实现自己的单元测试的呢？
不过在这个问题之前，应该还有几个准备性的问题的，就是：
1、大家都认为单元测试有必要么？
2、单元测试在实际工作中应该怎样操作？

关于第二点，我有一些个人的看法，我认为某个模块的单元测试是不应该由实现该模块的人员去设计的，否则就会卖花赞花了~~~本人建议具体操作中，可以让有关的开发人员的模块测试相互交叉，这是很有利于问题的发现的（当然了，你要是说到有可能相互包庇的话，那我认为这样的员工就没必要留下了^.^）。

--
相信那一片天空会因你的执着而晴朗

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[limodou]

2009/9/28 pyleaf <[hidden email]>:
> 有点标题党的嫌疑，哈哈~~
> 不知大家在实际工作中是怎样规划、设计、实现自己的单元测试的呢？
> 不过在这个问题之前，应该还有几个准备性的问题的，就是：
> 1、大家都认为单元测试有必要么？
> 2、单元测试在实际工作中应该怎样操作？
>
> 关于第二点，我有一些个人的看法，我认为某个模块的单元测试是不应该由实现该模块的人员去设计的，否则就会卖花赞花了~~~本人建议具体操作中，可以让有关的开发人员的模块测试相互交叉，这是很有利于问题的发现的（当然了，你要是说到有可能相互包庇的话，那我认为这样的员工就没必要留下了^.^）。
>

如果从测试驱动开发来说，测试代码要先写，才开始真正编码。所以是非做不可。不过一般可能还做不到这个程度。所以第一点，能做最好，很有必要。不过还是看公司或项目的要求，及能否达到这样的要求。

第二点一般的做法却正好是谁开发谁做，因为单元测试偏重于局部功能，比如某个类，某个模块，谁开发谁做是最有效的一种做法。至于怕出现卖花赞花可能是有，但是换别人做未必能做得好，或做得到位。其实这个还是看程序员的素质，换个人还不一定能做得多好呢。可能要具体情况具体分析吧。不过一般都是谁开发谁做。但是具体的运行或评估却不一定由开发者完成，这个我想有个管理方法的问题吧。

--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[pyleaf]

恩，就我知道而言，现在一般的公司也是如limodou所说那样去操作的。但是，也并不是所有公司都这么操作。之前参加了一个perl北京大会。会上，有人提到该怎么组织单元测试的操作，agentzh回答说他们就是开发人员相互交叉地对代码进行单元测试设计的。我觉得这个是一个挺合理的组织形式哦。因为假设开发人员有一个比较负责任的人，那么通过相互交叉的形式就可以激发其他人也要去负责任了。这个有点类似于掌权者不能同为监权者一样。呵呵~~~

2009/9/28 limodou <[hidden email]>:

> 2009/9/28 pyleaf <[hidden email]>:
>> 有点标题党的嫌疑，哈哈~~
>> 不知大家在实际工作中是怎样规划、设计、实现自己的单元测试的呢？
>> 不过在这个问题之前，应该还有几个准备性的问题的，就是：
>> 1、大家都认为单元测试有必要么？
>> 2、单元测试在实际工作中应该怎样操作？
>>
>> 关于第二点，我有一些个人的看法，我认为某个模块的单元测试是不应该由实现该模块的人员去设计的，否则就会卖花赞花了~~~本人建议具体操作中，可以让有关的开发人员的模块测试相互交叉，这是很有利于问题的发现的（当然了，你要是说到有可能相互包庇的话，那我认为这样的员工就没必要留下了^.^）。
>>
>
> 如果从测试驱动开发来说，测试代码要先写，才开始真正编码。所以是非做不可。不过一般可能还做不到这个程度。所以第一点，能做最好，很有必要。不过还是看公司或项目的要求，及能否达到这样的要求。
>
> 第二点一般的做法却正好是谁开发谁做，因为单元测试偏重于局部功能，比如某个类，某个模块，谁开发谁做是最有效的一种做法。至于怕出现卖花赞花可能是有，但是换别人做未必能做得好，或做得到位。其实这个还是看程序员的素质，换个人还不一定能做得多好呢。可能要具体情况具体分析吧。不过一般都是谁开发谁做。但是具体的运行或评估却不一定由开发者完成，这个我想有个管理方法的问题吧。
>
> --
> I like python!
> UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
> UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
> My Blog: http://hi.baidu.com/limodou
>
> >
>

--
相信那一片天空会因你的执着而晴朗

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[limodou]

2009/9/28 pyleaf <[hidden email]>:
> 恩，就我知道而言，现在一般的公司也是如limodou所说那样去操作的。但是，也并不是所有公司都这么操作。之前参加了一个perl北京大会。会上，有人提到该怎么组织单元测试的操作，agentzh回答说他们就是开发人员相互交叉地对代码进行单元测试设计的。我觉得这个是一个挺合理的组织形式哦。因为假设开发人员有一个比较负责任的人，那么通过相互交叉的形式就可以激发其他人也要去负责任了。这个有点类似于掌权者不能同为监权者一样。呵呵~~~
>

单元测试需要对代码有相当的了解，交叉测试需要互相非常熟悉代码，这与开发模式或管理模式有关，比如采用结对编程或AB角的方式。如果互相不熟悉代码，这件工作做起来很困难。但是现在许多公司这方面基本上是做不到的吧。所以我说要看具体情况，如果情况好是可以考虑的。开发者自已做单元测试我也说是通常的做法，并不是绝对的。只是大多数的情况是这样的。

--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[pyleaf]

的确是，相互交叉需要相对高的成本。

2009/9/28 limodou <[hidden email]>:

> 2009/9/28 pyleaf <[hidden email]>:
>> 恩，就我知道而言，现在一般的公司也是如limodou所说那样去操作的。但是，也并不是所有公司都这么操作。之前参加了一个perl北京大会。会上，有人提到该怎么组织单元测试的操作，agentzh回答说他们就是开发人员相互交叉地对代码进行单元测试设计的。我觉得这个是一个挺合理的组织形式哦。因为假设开发人员有一个比较负责任的人，那么通过相互交叉的形式就可以激发其他人也要去负责任了。这个有点类似于掌权者不能同为监权者一样。呵呵~~~
>>
>
> 单元测试需要对代码有相当的了解，交叉测试需要互相非常熟悉代码，这与开发模式或管理模式有关，比如采用结对编程或AB角的方式。如果互相不熟悉代码，这件工作做起来很困难。但是现在许多公司这方面基本上是做不到的吧。所以我说要看具体情况，如果情况好是可以考虑的。开发者自已做单元测试我也说是通常的做法，并不是绝对的。只是大多数的情况是这样的。
>
> --
> I like python!
> UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
> UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
> My Blog: http://hi.baidu.com/limodou
>
> >
>

--
相信那一片天空会因你的执着而晴朗

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[ubunoon-2]

总体给我的感觉是很少做单元测试，花不起单元测试的时间，尤其是一些项目很紧的公司，很少有时间去做单元测试。就好比要培养一个人一样，需要大量时间的，这是很多公司不希望的。

2009/9/28 pyleaf <[hidden email]>

的确是，相互交叉需要相对高的成本。

2009/9/28 limodou <[hidden email]>:

> 2009/9/28 pyleaf <[hidden email]>:
>> 恩，就我知道而言，现在一般的公司也是如limodou所说那样去操作的。但是，也并不是所有公司都这么操作。之前参加了一个perl北京大会。会上，有人提到该怎么组织单元测试的操作，agentzh回答说他们就是开发人员相互交叉地对代码进行单元测试设计的。我觉得这个是一个挺合理的组织形式哦。因为假设开发人员有一个比较负责任的人，那么通过相互交叉的形式就可以激发其他人也要去负责任了。这个有点类似于掌权者不能同为监权者一样。呵呵~~~
>>
>
> 单元测试需要对代码有相当的了解，交叉测试需要互相非常熟悉代码，这与开发模式或管理模式有关，比如采用结对编程或AB角的方式。如果互相不熟悉代码，这件工作做起来很困难。但是现在许多公司这方面基本上是做不到的吧。所以我说要看具体情况，如果情况好是可以考虑的。开发者自已做单元测试我也说是通常的做法，并不是绝对的。只是大多数的情况是这样的。
>
> --
> I like python!
> UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
> UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
> My Blog: http://hi.baidu.com/limodou
>
> >
>



--

相信那一片天空会因你的执着而晴朗

--
To be pythoner
My blog: http://www.cnblogs.com/ubunoon/


--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[He Yuqi]

又是一个没有结论的讨论。

我是认为做单元测试的项目比不做更省时间，项目更容易控制。不能只看到写测试代码要时间，单元测试覆盖率高能快速地找出项目集成的问题所在，会不会引发别的问题，另外启动调试也是很耗时的。

2009/9/28 ubunoon <[hidden email]>

总体给我的感觉是很少做单元测试，花不起单元测试的时间，尤其是一些项目很紧的公司，很少有时间去做单元测试。就好比要培养一个人一样，需要大量时间的，这是很多公司不希望的。

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[limodou]

2009/9/28 heyuqi <[hidden email]>:
> 又是一个没有结论的讨论。
>
> 我是认为做单元测试的项目比不做更省时间，项目更容易控制。不能只看到写测试代码要时间，单元测试覆盖率高能快速地找出项目集成的问题所在，会不会引发别的问题，另外启动调试也是很耗时的。
>

其实我认为最重要的是有好的工具和方法，比如使用doctest和nose。不过其它的语言做起来可能就不方便了。

--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[Chunlin Yang]

觉得如果一个项目或是一个产品需要长期的维护，那么单元测试是非常重要的。在维护阶段修改代码时，对被修改的单元重新跑一遍单元测试就知道修改对以前的功能有没有影响，然后再把新加入的部分的单元测试集成进去。

2009/9/28 limodou <[hidden email]>

2009/9/28 heyuqi <[hidden email]>:

> 又是一个没有结论的讨论。
>
> 我是认为做单元测试的项目比不做更省时间，项目更容易控制。不能只看到写测试代码要时间，单元测试覆盖率高能快速地找出项目集成的问题所在，会不会引发别的问题，另外启动调试也是很耗时的。
>

其实我认为最重要的是有好的工具和方法，比如使用doctest和nose。不过其它的语言做起来可能就不方便了。

--

I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[pyleaf]

我是支持在编码前设计单元测试，编码阶段性或者完成后执行测试用例的。
当然，在要求迅速反应的互联网环境下，有些公司的确舍不得花那些“昂贵”的时间，但至少我看到部分公司在国内正在尝试这些事情，还有一些公司正在朝着这个方向转变。测试，在国内还是很稚嫩，需要一些实践来说明其在任何项目中的必要性，我觉得这种实践的总结应该是落在开发人员身上的，因为开发者才能真正领会没有测试的后果跟苦恼。

2009/9/28 Chunlin Yang <[hidden email]>:

> 觉得如果一个项目或是一个产品需要长期的维护，那么单元测试是非常重要的。在维护阶段修改代码时，对被修改的单元重新跑一遍单元测试就知道修改对以前的功能有没有影响，然后再把新加入的部分的单元测试集成进去。
>
> 2009/9/28 limodou <[hidden email]>
>>
>> 2009/9/28 heyuqi <[hidden email]>:
>> > 又是一个没有结论的讨论。
>> >
>> >
>> > 我是认为做单元测试的项目比不做更省时间，项目更容易控制。不能只看到写测试代码要时间，单元测试覆盖率高能快速地找出项目集成的问题所在，会不会引发别的问题，另外启动调试也是很耗时的。
>> >
>>
>> 其实我认为最重要的是有好的工具和方法，比如使用doctest和nose。不过其它的语言做起来可能就不方便了。
>>
>> --
>> I like python!
>> UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
>> UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
>> My Blog: http://hi.baidu.com/limodou
>>
>>
>
>
> >
>

--
相信那一片天空会因你的执着而晴朗

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[jiabaozhen]

单元测试很重要啊。很多情况下，有单元测试的项目要不比没有的进度有保证。

道理其实很简单，一个项目或者系统，逻辑上是由多个单元组成的，如果每个单元是测试通过的，那么项目整体的质量就有更有保证，出了问题后，错误定位以及解决都要容易的多。就像linux下的写shell脚本一样，如果出现问题，我们只需要集中考虑脚本的逻辑处理，而不用担心脚本中用到的awk、sed、grep、cat等是否有bug，因为那些是经过充分测试的，发生bug的概率要小的多。

对于程序员而言，单元测试的重要性在于，你每前进一步，你都很明确的知道，你的前一步是坚实的，你的代码是可靠的。

而且，有了单元测试，你可以放心的进行重构，代码结构、代码实现可以信心满满的修改，因为一旦单元测试通过，你就知道，你的代码质量已经工作正常，你的重构工作已经完成。

越早的测试，对质量就越有信心，项目进度其实就会变得越可以控制。

有些人担心单元测试会影响项目进度，觉得太浪费时间了。还举刚才的例子，比如你用了一个新版本的类linux的操作系统，上面也提供了类似awk、sed、grep、cat的程序，但是这些都是没有经过充分测试的，现在你的shell脚本发现bug了，你怎么解决？大约我们会怀疑上上下下的很多东西。

实际实践一下TDD，就会发现，花在测试上的时间，真的是很值。

2009/9/28 pyleaf <[hidden email]>

我是支持在编码前设计单元测试，编码阶段性或者完成后执行测试用例的。
当然，在要求迅速反应的互联网环境下，有些公司的确舍不得花那些“昂贵”的时间，但至少我看到部分公司在国内正在尝试这些事情，还有一些公司正在朝着这个方向转变。测试，在国内还是很稚嫩，需要一些实践来说明其在任何项目中的必要性，我觉得这种实践的总结应该是落在开发人员身上的，因为开发者才能真正领会没有测试的后果跟苦恼。

--
贾保珍

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[ubunoon-2]

楼上这位说的好像很有道理，把linux下的awk，sed等都提出来了，看似很有依据，但是，这些都是一些比较小的程序，而且没有项目时间的限制，因此，只要有可能，就一定要把他做的最好。

如果给你一个月的时间，让你做这几个东西的集成，并且要有一定的业务逻辑，我想你就不会对这些东西有好说法了。

大部分时候，我们是需要不断修改我们的代码，甚至是接口，在代码还没有成行，逻辑未完全设计好，就进行测试，很困难。

测试的东西，应该是以产品形式发布的东西，项目的东西，应该尽量使用产品的东西，这样，才有可能保证项目的进度。

2009/9/28 Jia Baozhen <[hidden email]>

单元测试很重要啊。很多情况下，有单元测试的项目要不比没有的进度有保证。

道理其实很简单，一个项目或者系统，逻辑上是由多个单元组成的，如果每个单元是测试通过的，那么项目整体的质量就有更有保证，出了问题后，错误定位以及解决都要容易的多。就像linux下的写shell脚本一样，如果出现问题，我们只需要集中考虑脚本的逻辑处理，而不用担心脚本中用到的awk、sed、grep、cat等是否有bug，因为那些是经过充分测试的，发生bug的概率要小的多。

对于程序员而言，单元测试的重要性在于，你每前进一步，你都很明确的知道，你的前一步是坚实的，你的代码是可靠的。

而且，有了单元测试，你可以放心的进行重构，代码结构、代码实现可以信心满满的修改，因为一旦单元测试通过，你就知道，你的代码质量已经工作正常，你的重构工作已经完成。

越早的测试，对质量就越有信心，项目进度其实就会变得越可以控制。

有些人担心单元测试会影响项目进度，觉得太浪费时间了。还举刚才的例子，比如你用了一个新版本的类linux的操作系统，上面也提供了类似awk、sed、grep、cat的程序，但是这些都是没有经过充分测试的，现在你的shell脚本发现bug了，你怎么解决？大约我们会怀疑上上下下的很多东西。

实际实践一下TDD，就会发现，花在测试上的时间，真的是很值。

2009/9/28 pyleaf <[hidden email]>

我是支持在编码前设计单元测试，编码阶段性或者完成后执行测试用例的。

当然，在要求迅速反应的互联网环境下，有些公司的确舍不得花那些“昂贵”的时间，但至少我看到部分公司在国内正在尝试这些事情，还有一些公司正在朝着这个方向转变。测试，在国内还是很稚嫩，需要一些实践来说明其在任何项目中的必要性，我觉得这种实践的总结应该是落在开发人员身上的，因为开发者才能真正领会没有测试的后果跟苦恼。

--
贾保珍

--
To be pythoner
My blog: http://www.cnblogs.com/ubunoon/


--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[jiabaozhen]

这里说的是单元测试，不是产品的整体测试。

我的shell脚本的例子只是想说明，如果我们的代码使用了经过充分测试的库、单元、甚至函数等等，那么就能加速我们的开发，因为一旦出现bug，可以比较放心的限定一个范围，而不是从下向上、或者从上到下处处怀疑，处处测试。

实际上，项目越大，测试越重要，用一些豆腐渣砖块，怎么能建立起牢固的、可靠的建筑？

你说到：大部分时候，我们是需要不断修改我们的代码，甚至是接口，在代码还没有成行，逻辑未完全设计好，就进行测试，很困难。

其实，不管你的逻辑是什么样的，或者将来是什么样的，你既然开始写代码了，说明你已经知道输入、输出大体是什么了，只要有这个，你就能写测试代码。单元测试就是要测试，程序的输出和我预期的是否一致。无论你将来怎么修改代码，如果你只是修改算法实现，那么原来的测试用例就能复用，如果算法发生变化，那么就写新的测试用例。

不管哪种情况，修改一下代码，运行测试用例，通过了，说明代码工作ok，否则，返回去修改代码。

如果你的“逻辑未完全设计好”的程度到了没法开始写代码的程序，那么显然就无法写测试代码。

2009/9/28 ubunoon <[hidden email]>

测试的东西，应该是以产品形式发布的东西，项目的东西，应该尽量使用产品的东西，这样，才有可能保证项目的进度。

--
贾保珍

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

不知你们是什么样的程序？B/S C/S?

2009/9/28 Jia Baozhen <[hidden email]>

这里说的是单元测试，不是产品的整体测试。

我的shell脚本的例子只是想说明，如果我们的代码使用了经过充分测试的库、单元、甚至函数等等，那么就能加速我们的开发，因为一旦出现bug，可以比较放心的限定一个范围，而不是从下向上、或者从上到下处处怀疑，处处测试。

实际上，项目越大，测试越重要，用一些豆腐渣砖块，怎么能建立起牢固的、可靠的建筑？

你说到：大部分时候，我们是需要不断修改我们的代码，甚至是接口，在代码还没有成行，逻辑未完全设计好，就进行测试，很困难。

其实，不管你的逻辑是什么样的，或者将来是什么样的，你既然开始写代码了，说明你已经知道输入、输出大体是什么了，只要有这个，你就能写测试代码。单元测试就是要测试，程序的输出和我预期的是否一致。无论你将来怎么修改代码，如果你只是修改算法实现，那么原来的测试用例就能复用，如果算法发生变化，那么就写新的测试用例。

不管哪种情况，修改一下代码，运行测试用例，通过了，说明代码工作ok，否则，返回去修改代码。

如果你的“逻辑未完全设计好”的程度到了没法开始写代码的程序，那么显然就无法写测试代码。

2009/9/28 ubunoon <[hidden email]>

测试的东西，应该是以产品形式发布的东西，项目的东西，应该尽量使用产品的东西，这样，才有可能保证项目的进度。

--
贾保珍

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[jiabaozhen]

和B/S C/S无关，一个函数，一个类，一组类，都能做单元测试。

2009/9/28 @@ <[hidden email]>

不知你们是什么样的程序？B/S C/S?

--
贾保珍

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

话虽然这么说。不过我觉得难易还是有区别。
又比如一些ajax之类 这些如何能很方便的作单元测试

还有是不是会有这样的情况现有的代码你想加入单元测试，却发现这些代码很难作单元测试？

2009/9/28 Jia Baozhen <[hidden email]>

和B/S C/S无关，一个函数，一个类，一组类，都能做单元测试。

2009/9/28 @@ <[hidden email]>

不知你们是什么样的程序？B/S C/S?

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[jeff jie]

写测试单元就是在定义程序的输入输出，通常定义好某函数的输入输出后，单元已经OK了。

单元测试并没有想象的复杂，加之python的动态特性，没有了像Java那样需要一大堆MOCK来帮助测试的障碍。实现起来实易得多了。

好的习惯应该是更多时间花在写代码前，包括思考如何组织代码、各类或函数间的关系、测试单元，然后架子出来了（可能都是些空的类和函数），但接下来做的事情就简单咯。。

2009/9/28 @@ <[hidden email]>

话虽然这么说。不过我觉得难易还是有区别。
又比如一些ajax之类 这些如何能很方便的作单元测试

还有是不是会有这样的情况现有的代码你想加入单元测试，却发现这些代码很难作单元测试？

2009/9/28 Jia Baozhen <[hidden email]>

和B/S C/S无关，一个函数，一个类，一组类，都能做单元测试。

2009/9/28 @@ <[hidden email]>

不知你们是什么样的程序？B/S C/S?

--
185cm‘s自然卷：http://fallever.com
twitter:http://twitter.com/jeff_jie
试手机网,最好的在手机在线体验门户：http://shishouji.com
聪明的python主机webfaction：http://jeffjie.webfactional.com

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

厄。。其实我问的不是python。。
python我只用用django 写单元测试还是比较容易的。毕竟他们也为这个考虑过。
但是现在工作作的项目我觉得要去自己写单元测试实在是很难。。。

2009/9/28 jeff jie <[hidden email]>

写测试单元就是在定义程序的输入输出，通常定义好某函数的输入输出后，单元已经OK了。

单元测试并没有想象的复杂，加之python的动态特性，没有了像Java那样需要一大堆MOCK来帮助测试的障碍。实现起来实易得多了。

好的习惯应该是更多时间花在写代码前，包括思考如何组织代码、各类或函数间的关系、测试单元，然后架子出来了（可能都是些空的类和函数），但接下来做的事情就简单咯。。

2009/9/28 @@ <[hidden email]>

话虽然这么说。不过我觉得难易还是有区别。
又比如一些ajax之类 这些如何能很方便的作单元测试

还有是不是会有这样的情况现有的代码你想加入单元测试，却发现这些代码很难作单元测试？

2009/9/28 Jia Baozhen <[hidden email]>

和B/S C/S无关，一个函数，一个类，一组类，都能做单元测试。

2009/9/28 @@ <[hidden email]>

不知你们是什么样的程序？B/S C/S?

--
185cm‘s自然卷：http://fallever.com
twitter:http://twitter.com/jeff_jie
试手机网,最好的在手机在线体验门户：http://shishouji.com
聪明的python主机webfaction：http://jeffjie.webfactional.com

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[Widen]

我感觉单元测试非常重要，尤其是做产品需要长期维护的那种。但是现实中真正能够很好的应用的公司和团队非常少，但这不能说明单元测试可有可无，只能说明团队还需要尝试和努力提高整体水平才行。可以看看一些成功的开源项目，比如apache上的项目，或者googlecode上的比较成功的项目，单元测试基本上是必不可少的，否则就不可能成功，没有单元测试的话，在维护的过程中，无数的bug很快就会将这个项目覆灭。

以我个人的经验来说，单元测试能否很好的实现，关键在于开发团队的头（可能负责整体设计的架构师），他如果一开始就从整体上考虑到单元测试的架构，那么实现单元测试是很容易的，即使时间非常紧，也可以采取增量式的开发。也就是说第一个阶段的单元测试覆盖最核心的逻辑，而且随时随地的添加更多的覆盖逻辑，这样的话，慢慢的就有了非常完整的单元测试代码，在将来任何时候都可以随时的进行回归测试。现实中主要的问题是最初没有仔细规划，所以刚开始的时候可能写了部分单元测试代码能跑一跑，到最后完全跑不动了，最后整个结构乱了，而且因为时间的原因也没人愿意重构和整理。所以一开始就要有非常好的架构设计，加上非常严格的编码规范，就可以保证能够维护一个很好的单元测试代码。并且真正发挥单元测试的作用。

个人认为，单元测试对一个成功的项目，预期运行很多年的项目，是至关重要的。但这里面涉及到技术架构，也涉及到管理问题，学问不浅呵呵。

2009/9/28 @@ <[hidden email]>

厄。。其实我问的不是python。。
python我只用用django 写单元测试还是比较容易的。毕竟他们也为这个考虑过。
但是现在工作作的项目我觉得要去自己写单元测试实在是很难。。。

2009/9/28 jeff jie <[hidden email]>

写测试单元就是在定义程序的输入输出，通常定义好某函数的输入输出后，单元已经OK了。

单元测试并没有想象的复杂，加之python的动态特性，没有了像Java那样需要一大堆MOCK来帮助测试的障碍。实现起来实易得多了。

好的习惯应该是更多时间花在写代码前，包括思考如何组织代码、各类或函数间的关系、测试单元，然后架子出来了（可能都是些空的类和函数），但接下来做的事情就简单咯。。

2009/9/28 @@ <[hidden email]>

话虽然这么说。不过我觉得难易还是有区别。
又比如一些ajax之类 这些如何能很方便的作单元测试

还有是不是会有这样的情况现有的代码你想加入单元测试，却发现这些代码很难作单元测试？

2009/9/28 Jia Baozhen <[hidden email]>

和B/S C/S无关，一个函数，一个类，一组类，都能做单元测试。

2009/9/28 @@ <[hidden email]>

不知你们是什么样的程序？B/S C/S?

--
185cm‘s自然卷：http://fallever.com
twitter:http://twitter.com/jeff_jie
试手机网,最好的在手机在线体验门户：http://shishouji.com
聪明的python主机webfaction：http://jeffjie.webfactional.com

--
Chinese: http://www.jiakuan.net
English: http://www.widenhome.com

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

[kernel1983]

对于有一个固定目标的产品, 单元测试可以理解

但是如果团队在开发一个需求变动灵活的项目, 如何实际应用单元测试, 是一个问题.

On Sep 28, 9:09 pm, Widen <[hidden email]> wrote:

> 我感觉单元测试非常重要，尤其是做产品需要长期维护的那种。但是现实中真正能够很好的应用的公司和团队非常少，但这不能说明单元测试可有可无，只能说明团队还需要尝试和努力提高整体水平才行。可以看看一些成功的开源项目，比如apache上的项目，或者googlecode上的比较成功的项目，单元测试基本上是必不可少的，否则就不可能成功，没有单元测试的话，在维护的过程中，无数的bug很快就会将这个项目覆灭。
>
> 以我个人的经验来说，单元测试能否很好的实现，关键在于开发团队的头（可能负责整体设计的架构师），他如果一开始就从整体上考虑到单元测试的架构，那么实现单元测试是很容易的，即使时间非常紧，也可以采取增量式的开发。也就是说第一个阶段的单元测试覆盖最核心的逻辑，而且随时随地的添加更多的覆盖逻辑，这样的话，慢慢的就有了非常完整的单元测试代码，在将来任何时候都可以随时的进行回归测试。现实中主要的问题是最初没有仔细规划，所以刚开始的时候可能写了部分单元测试代码能跑一跑，到最后完全跑不动了，最后整个结构乱了，而且因为时间的原因也没人愿意重构和整理。所以一开始就要有非常好的架构设计，加上非常严格的编码规范，就可以保证能够维护一个很好的单元测试代码。并且真正发挥单元测试的作用。
>
> 个人认为，单元测试对一个成功的项目，预期运行很多年的项目，是至关重要的。但这里面涉及到技术架构，也涉及到管理问题，学问不浅呵呵。
>
> 2009/9/28 @@ <[hidden email]>
>
>
>
> > 厄。。其实我问的不是python。。
> > python我只用用django 写单元测试还是比较容易的。毕竟他们也为这个考虑过。
> > 但是现在工作作的项目我觉得要去自己写单元测试实在是很难。。。
>
> > 2009/9/28 jeff jie <[hidden email]>
>
> > 写测试单元就是在定义程序的输入输出，通常定义好某函数的输入输出后，单元已经OK了。
> >> 单元测试并没有想象的复杂，加之python的动态特性，没有了像Java那样需要一大堆MOCK来帮助测试的障碍。实现起来实易得多了。
>
> >> 好的习惯应该是更多时间花在写代码前，包括思考如何组织代码、各类或函数间的关系、测试单元，然后架子出来了（可能都是些空的类和函数），但接下来做的事情就简单咯。。
>
> >> 2009/9/28 @@ <[hidden email]>
>
> >>> 话虽然这么说。不过我觉得难易还是有区别。
> >>> 又比如一些ajax之类 这些如何能很方便的作单元测试
>
> >>> 还有是不是会有这样的情况现有的代码你想加入单元测试，却发现这些代码很难作单元测试？
>
> >>> 2009/9/28 Jia Baozhen <[hidden email]>
>
> >>>> 和B/S C/S无关，一个函数，一个类，一组类，都能做单元测试。
>
> >>>> 2009/9/28 @@ <[hidden email]>
>
> >>>>> 不知你们是什么样的程序？B/S C/S?
>
> >> --
> >> 185cm's自然卷：http://fallever.com
> >> twitter:http://twitter.com/jeff_jie
> >> 试手机网,最好的在手机在线体验门户：http://shishouji.com
> >> 聪明的python主机webfaction：http://jeffjie.webfactional.com
>
> --
> Chinese:http://www.jiakuan.net
> English:http://www.widenhome.com

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---