FreeOZ论坛

标题: 如果老板不同意我花时间写unit testing,该如何办啊? [打印本页]

作者: DDD888 时间: 6-12-2013 17:13
标题: 如果老板不同意我花时间写unit testing,该如何办啊?
今天我老板说项目很急,没有时间来给我写unit testing, 我写了两百多个unit testing 来测试javascript on browser side and C# asp.net mvc code, code coverage 大概只有20%. 他让我自己点网站来手工测试,我已经每天工作到晚上10点(没有加班费),你知道的写unit test很花时间,尤其是测试mysql database的代码,要将原来直接调用都改成interface,难度剧增,写那些mock,我都在摸索中

作者: DDD888 时间: 6-12-2013 17:19
老板是不懂写程序的

作者: 周星星1832 时间: 6-12-2013 17:21
不写
多简单

作者: 周星星1832 时间: 6-12-2013 17:24
哥原来参加大项目都不写
按你的描述应该不是大项目
老板都不要求
写毛啊

作者: michaelsusu 时间: 6-12-2013 17:28
I would advice you use "Squish" to perform quick test for your application.

http://www.froglogic.com/squish/gui-testing/

作者: DDD888 时间: 6-12-2013 17:44

周星星1832 发表于 6-12-2013 17:24

登录/注册后可看大图

哥原来参加大项目都不写
按你的描述应该不是大项目
老板都不要求

是大项目啦,C# asp.net mvc,javascript的代码有两万行啦,都是我一个人从头到底写出来的

作者: DDD888 时间: 6-12-2013 17:45
本帖最后由 DDD888 于 6-12-2013 17:51 编辑

周星星1832 发表于 6-12-2013 17:21

登录/注册后可看大图

不写
多简单

问题是老板要我保证网站100%正确,如果我修改了任何代码的 , 要自己先手工测试下,如果出错的话,就是我的责任啦,他就要说啦,去年给你加了30%的工资,就是希望你能够多担当些责任啦,

我听说新西兰一家公司开发网站,四个senior developer 开发后台数据库,前台八个senior developer 开发

弄到我开发,变成一个人开发,工资还没有十万新西兰元一年,唯一的好处就是在家里工作,但如前面所说,晚上写公司的程序到十点,没加班费.

作者: DDD888 时间: 6-12-2013 17:57

michaelsusu 发表于 6-12-2013 17:28

登录/注册后可看大图

I would advice you use "Squish" to perform quick test for your application.

http://www.froglogic. ...

你给的那个要卖钱的,老板连让我写测试都不肯,还会花钱去买软件来给我?

作者: michaelsusu 时间: 6-12-2013 18:23
本帖最后由 michaelsusu 于 6-12-2013 19:56 编辑

DDD888 发表于 6-12-2013 17:44

登录/注册后可看大图

是大项目啦,C# asp.net mvc,javascript的代码有两万行啦,都是我一个人从头到底写出来的

才2万行而已。哥你设计几个集成测试就可以了。
保证不死就可以了，小范围的错误是难免的。

作者: 周星星1832 时间: 6-12-2013 18:23

DDD888 发表于 6-12-2013 17:44

登录/注册后可看大图

是大项目啦,C# asp.net mvc,javascript的代码有两万行啦,都是我一个人从头到底写出来的

才两万行。。。。。还是一个人写。。。。
我也一个人写几万行的项目
就是写你也保证不了不出问题
你还加班到10点。。。。
何苦啊。。。。。。。

作者: DDD888 时间: 6-12-2013 18:28

周星星1832 发表于 6-12-2013 18:23

登录/注册后可看大图

才两万行。。。。。还是一个人写。。。。
我也一个人写几万行的项目
就是写你也保证不了不出问题

钦佩

那你的C# project 的Maintainablity Index 是多少啊?我写的是83

作者: 周星星1832 时间: 6-12-2013 18:45

DDD888 发表于 6-12-2013 18:28

登录/注册后可看大图

钦佩

那你的C# project 的Maintainablity Index 是多少啊?我写的是83

哥不写c#
哥写php或者java
c#好像写过半年
但是没注意

作者: DDD888 时间: 6-12-2013 18:48

周星星1832 发表于 6-12-2013 18:45

登录/注册后可看大图

哥不写c#
哥写php或者java
c#好像写过半年

i c

作者: DDD888 时间: 9-12-2013 10:07
我刚看到ncrunch不错,下了个来trial

作者: planetkeeper 时间: 10-12-2013 08:43
哎，又想质量好又要做得快
哪有这么好的事

作者: 艾瑞克 时间: 10-12-2013 08:49
老板不让写就不写呗，公司又不是你的，操那闲心干啥？
另外，lz该换工作了。

作者: DDD888 时间: 10-12-2013 09:01

DDD888 发表于 9-12-2013 10:07

登录/注册后可看大图

我刚看到ncrunch不错,下了个来trial

用了ncrunch到现在,真是太喜欢了,不用再自己按crtl+U+R

作者: DDD888 时间: 10-12-2013 09:03

ericvan76 发表于 10-12-2013 08:49

登录/注册后可看大图

老板不让写就不写呗，公司又不是你的，操那闲心干啥？
另外，lz该换工作了。

为啥我该换工作啊?

作者: DDD888 时间: 10-12-2013 09:15

ericvan76 发表于 10-12-2013 08:49

登录/注册后可看大图

老板不让写就不写呗，公司又不是你的，操那闲心干啥？
另外，lz该换工作了。

写unit test 是对自己一个挑战,可以提高自己的钻研精神啦

作者: DDD888 时间: 10-12-2013 09:29

planetkeeper 发表于 10-12-2013 08:43

登录/注册后可看大图

哎，又想质量好又要做得快
哪有这么好的事

是的,这真是又要马儿跑的快,又要马儿少吃草

作者: cais 时间: 10-12-2013 23:22
当然要写了。就算不是做TDD，写完code再写test，很多时间也能发现不少bug的。
LZ的javascript unit test用什么framework写的。用工具跑你的unit test?
把code改成testable的基于interface的，是正确的方向。改完了，以后日子就好过了。
除了unit test，也要做integration test。基于web的，弄几个selenium之类的test也很不错。
你不需要告诉老板你是在写test。就说是在改程序就好了。老板难道会去查你的svn/git的历史看你在写什么吗？

作者: DDD888 时间: 11-12-2013 05:23
本帖最后由 DDD888 于 11-12-2013 05:28 编辑

cais 发表于 10-12-2013 23:22

登录/注册后可看大图

当然要写了。就算不是做TDD，写完code再写test，很多时间也能发现不少bug的。
LZ的javascript unit test用 ...

是的,这正是我想做的

我是用http://qunitjs.com/ 做javascript unit testing的,很简单的

自己手工点test page
我用selenium webdriver c# firefox来做integration test,但要写的测试也是非常复杂的,我只写了一两个简单的测试

作者: planetkeeper 时间: 11-12-2013 08:40
正儿八经搞unit test，selenium test automation，都是全职的活。。。
你一个全包，这你也能忍。。。

作者: black_zerg 时间: 11-12-2013 08:48
提示: 作者被禁止或删除, 无法发言 能卖钱就是好代码。unit testing 不是java的传统么，js也要了？我是从来对TDD不以为然的，反生产力，不过只要有助卖钱就干。

作者: DDD888 时间: 11-12-2013 09:04

black_zerg 发表于 11-12-2013 08:48

登录/注册后可看大图

能卖钱就是好代码。unit testing 不是java的传统么，js也要了？我是从来对TDD不以为然的，反生产力，不过只 ...

unit testing 让我想到了java 里的j2ee里的那些entity bean,莫名其妙增加了许多工作量,但unit testing 确实是好技术

作者: DDD888 时间: 11-12-2013 09:06
本帖最后由 DDD888 于 11-12-2013 09:18 编辑

planetkeeper 发表于 11-12-2013 08:40

登录/注册后可看大图

正儿八经搞unit test，selenium test automation，都是全职的活。。。
你一个全包，这你也能忍。。。

没办法了,老板说要让我100%保证修改后没有错误,只能用最好的技术来做啦,公司里没有测试人员,就靠老板和财务点点网页,还有就是客户来报错啦,那后果很严重啦

我的工作还包括开发维护android应用,实现了网站的所有功能,工作量是挺大的.不过今天财务打电话告诉我说,老板给员工发nz$200现金作为圣诞节礼物

作者: planetkeeper 时间: 11-12-2013 09:18
哎，就这样才给80k？

作者: DDD888 时间: 11-12-2013 09:51

planetkeeper 发表于 11-12-2013 09:18

登录/注册后可看大图

哎，就这样才给80k？

超过80k

作者: 艾瑞克 时间: 11-12-2013 10:01

DDD888 发表于 10-12-2013 07:15

登录/注册后可看大图

写unit test 是对自己一个挑战,可以提高自己的钻研精神啦

写unit test不是挑战，
写最少的unit test，出最高质量的代码才是挑战。

作者: planetkeeper 时间: 11-12-2013 13:19

DDD888 发表于 11-12-2013 09:51

登录/注册后可看大图

超过80k

恭喜涨薪水

作者: DDD888 时间: 11-12-2013 14:18

planetkeeper 发表于 11-12-2013 13:19

登录/注册后可看大图

恭喜涨薪水

谢谢

我的目标是年收入十五万新西兰元,理想的话能达到二十万新西兰元更好,但如果能自己有项目,自己作老板那就更好了

作者: DDD888 时间: 11-12-2013 14:20
本帖最后由 DDD888 于 11-12-2013 14:21 编辑

ericvan76 发表于 11-12-2013 10:01

登录/注册后可看大图

写unit test不是挑战，
写最少的unit test，出最高质量的代码才是挑战。

那就变得说不清了,我的目标是maintainability index 在80以上,能用最少的代码来完成项目,如果不写代码能做到同样的效果那就更好了

代码要同时支持上万个concurrent connection,速度运行要飞快,时刻作benchmark

作者: 艾瑞克 时间: 11-12-2013 14:31

DDD888 发表于 11-12-2013 12:20

登录/注册后可看大图

那就变得说不清了,我的目标是maintainability index 在80以上,能用最少的代码来完成项目,如果不写代码能 ...

你没懂我的意思

作者: 阿贞 时间: 11-12-2013 14:38
提示: 作者被禁止或删除, 无法发言 这帖子的讨论感觉很怪，新出来跑江湖的？

作者: DDD888 时间: 11-12-2013 14:56

Samantabhadra 发表于 11-12-2013 14:38

登录/注册后可看大图

这帖子的讨论感觉很怪，新出来跑江湖的？

看不懂你想说的意思?

作者: DDD888 时间: 11-12-2013 14:56

ericvan76 发表于 11-12-2013 14:31

登录/注册后可看大图

你没懂我的意思

啥意思?

作者: 艾瑞克 时间: 11-12-2013 15:07

DDD888 发表于 11-12-2013 12:56

登录/注册后可看大图

啥意思?

我不是说不写test或者少写test，我说的是生产力的问题，这东西说来话长，现在没空说。

作者: Daibaw 时间: 11-12-2013 20:58
就算不是TDD，unit test的好处不用多言，不过这好处很多都只是从程序员角度而言，换句话说就是干活容易了
high unit test coverage的项目，维护起来要轻松不少，特别是长期项目，相比之下改点小东西把别的地方搞爆了的可能性比较小一些，最起码也是peace of mind
但是从老板的角度，这里头有没有价值产出就未必了（起码短期如此），好的测试框架花的人月，恐怕比写code都少不到哪去
当然日后加feature改bug一不小心把哪里弄挂了还是你的责任就是了
这世道就是又要马儿跑又要少吃草

作者: cais 时间: 11-12-2013 23:12

DDD888 发表于 11-12-2013 05:23

登录/注册后可看大图

是的,这正是我想做的

我是用http://qunitjs.com/ 做javascript unit testing的,很简单的:loveliness ...

我们也是用QUnit。
你可以写个简单的script，用来跑Qunit。就可以像你的webdriver一样，自动化了。
然后用个bamboo之类的build server。老板不给钱的话，就弄个jenkins之类的免费的也行。
每次有commit，就自动跑测试，junit/qunit/webdriver都自动跑。
对于regression很有帮助。对于增加自己对程序质量的信心也很有帮助。
唯一的坏处，就是对老板太有好处了。他想换掉你的时候，需要考虑的因素少了好几个。估计只要考虑把source control跟build server这两个东西抓在手里就行了。

真不明白你老板是怎么想的。这种对他这么有利的事情，居然还阻止你去做。

作者: cais 时间: 11-12-2013 23:14

planetkeeper 发表于 11-12-2013 08:40

登录/注册后可看大图

正儿八经搞unit test，selenium test automation，都是全职的活。。。
你一个全包，这你也能忍。。。

test本来就是开发的一部分，只是有些人喜欢手动测试而已。
unit test跟webdriver test，刚开始需要做一些基本的工作，设置好了，每次再加test case就不算太麻烦。

作者: cais 时间: 11-12-2013 23:16

black_zerg 发表于 11-12-2013 08:48

登录/注册后可看大图

能卖钱就是好代码。unit testing 不是java的传统么，js也要了？我是从来对TDD不以为然的，反生产力，不过只 ...

写test不一定就是TDD。反不反生产力也很难说。
一次性的卖钱，跟连续卖钱，也是有区别的。
只是一次性卖一个看起来可以跑的程序，可能就不太需要test。

作者: cais 时间: 11-12-2013 23:18

DDD888 发表于 11-12-2013 09:06

登录/注册后可看大图

没办法了,老板说要让我100%保证修改后没有错误,只能用最好的技术来做啦,公司里没有测试人员,就靠老板和 ...

手机的自动化测试还没做过。据说android的比iphone的要好很多。
不过最少服务器方面的api应该是可以做到自动化测试的。

作者: 美羽mm 时间: 12-12-2013 02:02
身为文科生兼电脑半文盲，看着一群的牛人在讨论写程序真是云里雾里

作者: black_zerg 时间: 12-12-2013 07:35
提示: 作者被禁止或删除, 无法发言 本帖最后由 black_zerg 于 12-12-2013 08:17 编辑

http://programmers.stackexchange ... egative-experience. 简单说你时间有限，如何分配时间在优化设计，重构代码，补充文档还是一堆测试上，各人观点不同。如果你老板认可，那测试就是有助卖钱，这理由就够了。j2ee里过度设计一堆，估计从c sharp 也差不多。意义也有，提高入门门槛，简单事情变复杂，大家都有活干。系统修改起来流程也变复杂，新人没有这些背景知识根本没法入手。十年前一个jsp解决的事现在起码得十个文件以上还不包括测试。绝大多数都是单实现，所以面向接口也是纯浪费。但是如果一大帮人几年守着一个系统，不写测试也没事干。纯从技术上谈，就是得看性价比。如果你不写那么多测试，时间花在设计和代码重构，导致系统更优化，代码清晰容易扩展，没bug,这就一点问题没有。我经历过一些渣系统，上千unit test都是绿条，除了好看没任何意义。但是如果你有很多预算，设计和代码上已经做到极致，那再多测试当然都合理。

作者: planetkeeper 时间: 12-12-2013 08:36

cais 发表于 11-12-2013 23:14

登录/注册后可看大图

test本来就是开发的一部分，只是有些人喜欢手动测试而已。
unit test跟webdriver test，刚开始需要做一些 ...

我以前就做过测试自动化，维护test automation framework并不是那么简单的
这不比code base，尤其是web应用，feature update的频率很快

测试framework一旦没人维护，很快就不能满足QA的需求了
要不然也不会有公司100k招聘test automation specialist了

作者: planetkeeper 时间: 12-12-2013 08:37

DDD888 发表于 11-12-2013 14:18

登录/注册后可看大图

谢谢

我的目标是年收入十五万新西兰元,理想的话能达到二十万新西兰元更好,但如果能自己有项目,自己作老 ...

对头，既然你现在就是one man army的话，为啥不自己做呢

作者: DDD888 时间: 12-12-2013 09:32

planetkeeper 发表于 12-12-2013 08:37

登录/注册后可看大图

对头，既然你现在就是one man army的话，为啥不自己做呢

不知道做啥项目?

作者: DDD888 时间: 12-12-2013 09:34

black_zerg 发表于 12-12-2013 07:35

登录/注册后可看大图

http://programmers.stackexchange ... egative-experience. 简单说你时间有限，如何 ...

我写了两百多个unit test, 找到了两个bug,但实际应用中这两个bug根本就不会遇到,当然我假设我做的unit test还是取得了成果,找到了两个bug

作者: black_zerg 时间: 12-12-2013 09:49
提示: 作者被禁止或删除, 无法发言 本帖最后由 black_zerg 于 12-12-2013 09:56 编辑

spot on 所以你这两百多用例的产出就是发现了这两个实际根本不会发生的bug，这个时间也许不如用在学习或者思考架构优化上，特别你是单干有这个自由度。我认为程序员的强度决定程序强度，很多完全不懂写程序的一样可以大吹各种开发模式，但其实都是浮云，渣程序员一样写渣程序。有的程序员程序都写不明白，非要写测试用例那只能更悲催。强程序员写的本身就不会有大问题，因为实际都是边写边测，不会写一堆代码就提交。在这个前提下，写太多正式测试是浪费资源，还有个问题就是自己测自己写的容易遗漏。你不如叫老板找个人给你手动测用例

作者: 艾瑞克 时间: 12-12-2013 11:07
本帖最后由 ericvan76 于 12-12-2013 09:10 编辑

DDD888 发表于 12-12-2013 07:34

登录/注册后可看大图

我写了两百多个unit test, 找到了两个bug,但实际应用中这两个bug根本就不会遇到,当然我假设我做的unit ...

如果我写200个unit tests，那么大概就一定有两百个pattern各不相同的case。如果我是老板，我一定不愿意花钱让你去写unit test去发现实际应用中根本不会遇到的bug。pattern雷同的东西，无论是code还是test，我只会把时间花在code-gen上，省时省力，而且100% coverage，当然，有一大半CRUD也许是实际用不着的。

也许你会说code-gen有局限性，是，当然，任何东西都有局限性，就像black_zerg说的，如果你把时间用在学习或者思考架构优化上，那么就有减少局限性的可能。

作者: DDD888 时间: 12-12-2013 11:09

black_zerg 发表于 12-12-2013 09:49

登录/注册后可看大图

spot on 所以你这两百多用例的产出就是发现了这两个实际根本不会发生的bug，这个时间也许不如用在学习或者思 ...

勿以善小而不为,unit test相当于有一个人一直在peer review code change,好处是不可估量的

作者: Daibaw 时间: 12-12-2013 21:11

DDD888 发表于 12-12-2013 11:09

登录/注册后可看大图

勿以善小而不为,unit test相当于有一个人一直在peer review code change,好处是不可估量的

确实，unit test其实很容易上瘾，习惯了就会离不开，而且好的unit test框架作用远不止于peer review，而是正规化的自动回归测试，有了unit test以后最爽的事莫过于N个月后改了某个看起来根本不相关的地方结果把某个test case给弄fail了，等于是省下了大把潜在的debug时间精力

但问题也就出在这个“潜在”上面，unit test最大的价值是防患于未然，既然是未然那它的价值就很难直接体现。传统的瀑布开发容易被人诟病的就是unit test这个环节根本找不出几个bug，所以counter productive，其实这个正常的很，既然test case和code都是同一个人写的，当场要是还能捉出大堆bug那就是code水平问题了（即使有多半也是在code阶段立马就改了）。unit test的真正目的是把编码阶段的意图持久化，某种意义上就是一个contract，日常实践里太多bug就是因为开发者几个月以后忘记了某个逻辑的原始意图乱改（改别人code的时候这问题更普遍），结果就是程序里没人敢碰的地方越来越多，最后加个注释here be dragon完事，unit test真正需要解决的就是这个问题。但这种看不见摸不着的产出就很难可视化，因此不讨老板喜欢也是常事

而且unit test实践起来要发挥作用，需要很多条件，这些条件在很多小公司很难实现。首先就是code本身必须是可测试的，可测试的先决条件是松散耦合，高度模块化，土澳这地方面条代码大行其道，很多时候想搞几个case都得把程序大卸八块整个refactor一遍才行（而测试还没完善以前的refactor风险巨大）；然后是对开发团队也有要求，起码参与项目的人都得对这玩意有相当程度的认识，遗憾实际上在澳洲（国内其实也一样），多的是从vb起步自学成才的coder，整个思维方式都是RAD的，根本看不到unit test的好处，结果就是费了N个人月整出来的test framework最后流于形式。工作多年的人mindset很难改变（按stackoverflow的某个讨论的说法就是得brain transplant才行），很多好coder都想去MS之类的公司工作，而大公司也喜欢直接从学校招人，这方面也是一个原因。另外就是项目的规模要足够大，维护周期要够长，unit test是维护时间越久越体现价值的东西，如果是一锤子卖钱的项目就很难搞，因为从成本考虑，overhead可是看得见摸得着的。澳洲缺少做产品的公司，这方面也是一个劣势

作者: cais 时间: 12-12-2013 21:22
见仁见智。架构上设计上的问题，当然要考虑。但是那跟写不定test没有太大关系。
现在讨论得比较多的unit test，是相对于一个小模块，一个个小class而言的。架构再怎么好，也要保证小的地方实现是正确的。
前面有人说好的程序员是边写边测。如果那些“边测”是手动做的话，
过了一段时间想改一点东西，就要重新手动去测以前测过的东西。大部份人应该都不会那样做的。造成的结果就是只测一部份关键的地方。
这样就很容易出现bug。如果以前多花一点时间把边写边测的那些test都变得自动化了，以后改动起来信心就大很多了。
另外，testing不只是unit test。还有integration test, webdriver test, performance test等等。
前几天，我就碰到被performance test发现了我弄出来的一个bug。那个pull request是经过三个senior developers review过的。

今天我们做restrospective的时候，同事们纷纷表示前一段时间花也好久做这个performance test是值得的。
我觉得test是维护你的系统的一种手段。当系统变得很大的时候，手动的手段就显得行不太通，因为不scalable。
所以现在这种自动化测试，continuous integration, continuous deployment之类的东西才会比较流行。
test写得好，跟架构设计那些东西是没有冲突。如果你要改动架构，没有integration test的话，很难保证改了之后不会出问题。
没有performance test，怎么知道改了之后性能没有降低。
以上是我这几个月在新公司被洗脑之后的结果。。。

仅供大家参考。

作者: black_zerg 时间: 12-12-2013 21:50
提示: 作者被禁止或删除, 无法发言 本帖最后由 black_zerg 于 12-12-2013 22:03 编辑

关键在于需求不断变化,很多公司是做系统不是做产品。而且写那种处处mock的测试真是枯燥无比，最后还是不能替代手测。我个人的判断就是通讯，与其他系统的接口，帐务计算这些，应当写测试。如果一堆crud界面之类还写测试，只能羡慕有闲情。我曾经写过一个测试框架读脚本自动登录点地图填报单提交之类，但实际上是因为客户要我又有空，各个用例自动跑看着挺好玩的，其实没多大意义，代替不了uat
性能测试或者说压力测试我倒是很赞成的

作者: DDD888 时间: 13-12-2013 06:45
我给自己设立了一个规定,新改的程序都要写unit test, 如果有空的话,逐渐给legacy code加unit test

作者: DDD888 时间: 13-12-2013 07:00

black_zerg 发表于 12-12-2013 21:50

登录/注册后可看大图

关键在于需求不断变化,很多公司是做系统不是做产品。而且写那种处处mock的测试真是枯燥无比，最后还是不能替 ...

顺便问一下,我本来都是用StrictMock的,后来书上说DynamicMock好,我就用了DynamicMock,后来又读到Stub好,现在都用Stub,我发觉原来用StrictMock改成Stub,那些测试也都通过了,StrictMock和Stub有啥区别啊?我是用Rhino.Mocks

作者: planetkeeper 时间: 13-12-2013 08:46
one man army应付小项目还可以，大的项目我无法想象怎么可能一个人做的过来
我也很难想象习惯了TDD，continuous integration的人，会愿意回归到原始的waterfall。。。

作者: DDD888 时间: 13-12-2013 09:51

planetkeeper 发表于 13-12-2013 08:46

登录/注册后可看大图

one man army应付小项目还可以，大的项目我无法想象怎么可能一个人做的过来
我也很难想象习惯了TDD，conti ...

啥是小项目,啥是大项目?

作者: 羊头党 时间: 13-12-2013 14:36
根据需要决定是否要写Unit Test。

作者: DDD888 时间: 14-12-2013 05:25

cais 发表于 11-12-2013 23:12

登录/注册后可看大图

我们也是用QUnit。
你可以写个简单的script，用来跑Qunit。就可以像你的webdriver一样，自动化了。
然后 ...

我写的unit test

namespace UnitTest.Qunit
{
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using OpenQA.Selenium.Firefox;

[TestClass]
public class UnitTestQunit
{
      [TestMethod]
      [TestCategory("QUnit")]
      public void RunQUnitInFirefox_ExpectNoFail()
      {
         var driver = new FirefoxDriver();
         var navigator = driver.Navigate();

         // Currently, max execution time is one minute.
         driver.Manage().Timeouts().SetScriptTimeout(new TimeSpan(0, 1, 0));
         navigator.GoToUrl(@"http://localhost/unittest/qunit.html");
         var failedTests = driver.FindElementsByClassName("fail");
         Assert.AreEqual(0, failedTests.Count);
         driver.Quit();
      }
}
}

作者: DDD888 时间: 14-12-2013 05:28

cais 发表于 12-12-2013 21:22

登录/注册后可看大图

见仁见智。架构上设计上的问题，当然要考虑。但是那跟写不定test没有太大关系。
现在讨论得比较多的unit t ...

你们公司挺厉害的,一个change要三个人来review,那这样一来万一老板要辞退一个人,可以有三个人来代替

作者: planetkeeper 时间: 16-12-2013 08:34

DDD888 发表于 13-12-2013 09:51

登录/注册后可看大图

啥是小项目,啥是大项目?

按代码量，复杂度访问率等多个指标来衡量

作者: DDD888 时间: 16-12-2013 09:08
本帖最后由 DDD888 于 16-12-2013 09:09 编辑

planetkeeper 发表于 16-12-2013 08:34

登录/注册后可看大图

按代码量，复杂度访问率等多个指标来衡量

谢谢,我感觉我做的是大项目啦

我现在做的网站的同样类似功能的项目在我以前曾工作的公司大概需要十个人(6 programmers + 1 team leader + 3 qa)来做两年啦,那时是用j2ee orion application server用java开发,当然现在只要个iis用asp.net mvc就行了.

作者: planetkeeper 时间: 16-12-2013 13:28

DDD888 发表于 16-12-2013 09:08

登录/注册后可看大图

谢谢,我感觉我做的是大项目啦

我现在做的网站的同样类似功能的项目在我以前曾工作的公司大概需要十个 ...

这方面的技术我都不懂，不过如果你现在一个人做一个大项目的话

还要应该要求加人手，延长工期或者加薪水的

作者: workinvm 时间: 16-12-2013 14:43
项目大小我觉得应该看参与项目的人的多少，不光是开发还有测试，维护，销售，项目管理等。楼主还是挺牛的，一个人搞这么多，还这么认真负责。只是有一点，没有100%没有问题的程序，你单元测试覆盖率100%也不能保证没有问题。就是程序完全正确，还存在系统问题，还可能出现需求理解问题，各个层面上都会出现问题，我觉得最重要的还是老板要理解，不出大问题就成。你老板那样的，很难共事，炒了他得了。

作者: 土豆烧牛肉 时间: 16-12-2013 23:32
同意炒了老板算了

作者: DDD888 时间: 17-12-2013 12:28

土豆烧牛肉发表于 16-12-2013 23:32

登录/注册后可看大图

同意炒了老板算了

现在全球经济这样差,没了工作也还是要养家的呀

作者: 土豆烧牛肉 时间: 17-12-2013 18:43
骑驴找马，看这个样子是你老板离不开你

作者: cais 时间: 17-12-2013 23:26

DDD888 发表于 14-12-2013 05:25

登录/注册后可看大图

我写的unit test

namespace UnitTest.Qunit

对大概就是这种东西。只要能起一个browser再跑一下全部qunit test就行了。
我们的好像是一个个Test的点。

作者: cais 时间: 17-12-2013 23:33

DDD888 发表于 14-12-2013 05:28

登录/注册后可看大图

你们公司挺厉害的,一个change要三个人来review,那这样一来万一老板要辞退一个人,可以有三个人来代替

不能老是想着要辞退。真的天天要担心被辞退的话，就不应该在这个公司上班了。
没有什么人是不可或缺的。就算整个app你见都没见过，老板让你接手，你还不是要接手。

code review也只能一定程度上发现一些问题。

作者: planetkeeper 时间: 18-12-2013 10:08

cais 发表于 17-12-2013 23:33

登录/注册后可看大图

不能老是想着要辞退。真的天天要担心被辞退的话，就不应该在这个公司上班了。
没有什么人是不可 ...

code review能发现的，测试都能发现
code review只是个placebo

作者: DDD888 时间: 18-12-2013 12:16

planetkeeper 发表于 18-12-2013 10:08

登录/注册后可看大图

code review能发现的，测试都能发现
code review只是个placebo

我发现code review只不过是走形式啦,一点用都没有

作者: 艾瑞克 时间: 18-12-2013 12:26
本帖最后由 ericvan76 于 18-12-2013 10:29 编辑

planetkeeper 发表于 18-12-2013 08:08

登录/注册后可看大图

code review能发现的，测试都能发现
code review只是个placebo

不一定啦，如果让code review和test去发现同样的问题，那其实没什么意思，我倒是觉得code review是在做不同的事。打个比方，很多时候对于新手，会要求做code review，新手做的东西，往往功能实现了，test也ok，但在某些地方会存在一些潜在的问题，当时也许暴露不出来，也不一定是错误，但可能以后会有麻烦，我不知道具体怎么说，带过新手的人应该能明白。

作者: planetkeeper 时间: 18-12-2013 12:39

ericvan76 发表于 18-12-2013 12:26

登录/注册后可看大图

不一定啦，如果让code review和test去发现同样的问题，那其实没什么意思，我倒是觉得code review是在做 ...

带新手用code review是非常低效的方法，design阶段就应该把关，等code review再查这些设计问题
事倍功半

作者: 艾瑞克 时间: 18-12-2013 12:44
本帖最后由 ericvan76 于 18-12-2013 10:51 编辑

planetkeeper 发表于 18-12-2013 10:39

登录/注册后可看大图

带新手用code review是非常低效的方法，design阶段就应该把关，等code review再查这些设计问题
事倍功半

我有说过是设计问题么？

我只是拿新手来打个比方，其实我只想说，code review和test的功能是不一样的，针对你的这句话“code review能发现的，测试都能发现”。

作者: DDD888 时间: 18-12-2013 13:10
我记的我以前工作的公司也没啥带新手,就是让新手来改错,资深程序员开发新项目和新功能

作者: planetkeeper 时间: 18-12-2013 13:18

ericvan76 发表于 18-12-2013 12:44

登录/注册后可看大图

我有说过是设计问题么？

我只是拿新手来打个比方，其实我只想说，code review和test的功能是不一样 ...

code review和test的功能是不一样，不过如果code review能发现unit test测不出的问题
那么这个unit test要重写了

作者: 艾瑞克 时间: 18-12-2013 13:27

planetkeeper 发表于 18-12-2013 11:18

登录/注册后可看大图

code review和test的功能是不一样，不过如果code review能发现unit test测不出的问题
那么这个unit test ...

Agree to disagree.

作者: planetkeeper 时间: 18-12-2013 13:31

ericvan76 发表于 18-12-2013 13:27

登录/注册后可看大图

Agree to disagree.

disagree to agree

作者: cais 时间: 18-12-2013 23:35

planetkeeper 发表于 18-12-2013 13:18

登录/注册后可看大图

code review和test的功能是不一样，不过如果code review能发现unit test测不出的问题
那么这个unit test ...

code review的时候，连test codes也一起review的。
有些问题改了之后，需要改test。有些不是。
有很多介于design跟implementation之间的问题，只能通过code review发现。

作者: cais 时间: 18-12-2013 23:37

ericvan76 发表于 18-12-2013 12:26

登录/注册后可看大图

不一定啦，如果让code review和test去发现同样的问题，那其实没什么意思，我倒是觉得code review是在做 ...

带新手的话，个人觉得pair programming是挺不错的一个选择。基本上是手把手教啊。

当然这个“新手”是指新来的人。不一定是没有经验的人。

作者: planetkeeper 时间: 19-12-2013 09:33

cais 发表于 18-12-2013 23:35

登录/注册后可看大图

code review的时候，连test codes也一起review的。
有些问题改了之后，需要改test。有些不是。
有很多介 ...

没错，不过我就是不太赞同过于依赖code review
比如有些地方ut都没做，就靠code review来把关。。。

作者: kiluyar 时间: 19-12-2013 10:05
还是我个公司神，没有code review, 没有 unit test,有时候甚至没有测试就发布了

作者: 艾瑞克 时间: 19-12-2013 10:12

planetkeeper 发表于 19-12-2013 07:33

登录/注册后可看大图

没错，不过我就是不太赞同过于依赖code review
比如有些地方ut都没做，就靠code review来把关。。。

我也没说“过于依赖code review”啊，你这个人吧，总是喜欢把别人的看法极端化。

作者: planetkeeper 时间: 19-12-2013 10:12

kiluyar 发表于 19-12-2013 10:05

登录/注册后可看大图

还是我个公司神，没有code review, 没有 unit test,有时候甚至没有测试就发布了

彻底败了，土澳果然是个神奇的地方
总是能刷新我的认知极限

作者: planetkeeper 时间: 19-12-2013 10:37

ericvan76 发表于 19-12-2013 10:12

登录/注册后可看大图

我也没说“过于依赖code review”啊，你这个人吧，总是喜欢把别人的看法极端化。

那就好好说话，不要为了反对而反对

作者: 艾瑞克 时间: 19-12-2013 10:42
本帖最后由 ericvan76 于 19-12-2013 08:53 编辑

planetkeeper 发表于 19-12-2013 08:37

登录/注册后可看大图

那就好好说话，不要为了反对而反对

呵呵，为了反对而反对，这话从你嘴里说出来真可笑。

我觉得只是持有不同看法而已，不存在什么反对不反对。

你去看我回你的第一个帖子的第一句话，我用了“不一定”，后面是”我觉得“，都还算比较婉转吧，我可没说什么“反对”，“错”这样的字眼吧。

这还不算好好说话你想怎样？好好的讨论气氛都让你给破坏了。

作者: planetkeeper 时间: 19-12-2013 10:53

ericvan76 发表于 19-12-2013 10:42

登录/注册后可看大图

呵呵，为了反对而反对，这话从你嘴里说出来真可笑。

我觉得只是持有不同看法而已，不存在什么反对不 ...

噗，这是在自抽吗？

观点不同很正常，谁在为反对而反对，一目了然

作者: 艾瑞克 时间: 19-12-2013 11:10

planetkeeper 发表于 19-12-2013 08:53

登录/注册后可看大图

噗，这是在自抽吗？

观点不同很正常，谁在为反对而反对，一目了然

如果非要吵到谁先闭嘴谁就输的话，ok，这是我最后一贴，然后您一定会再反驳我一次，你赢了。

作者: planetkeeper 时间: 19-12-2013 11:18
好好的讨论帖子，有些人就是喜欢来歪楼，歪完然后说这都是你的错

作者: kiluyar 时间: 19-12-2013 12:02

planetkeeper 发表于 19-12-2013 10:12

登录/注册后可看大图

彻底败了，土澳果然是个神奇的地方
总是能刷新我的认知极限

刚才鬼佬同事说要提前下班，我告诉他他做的东西有点问题，结果人家一脸不高兴。。。
唉。。。以后不管了

作者: DDD888 时间: 19-12-2013 13:18

kiluyar 发表于 19-12-2013 12:02

登录/注册后可看大图

刚才鬼佬同事说要提前下班，我告诉他他做的东西有点问题，结果人家一脸不高兴。。。
唉。。。以后不管了

人之常情

作者: kiluyar 时间: 19-12-2013 13:48

DDD888 发表于 19-12-2013 13:18

登录/注册后可看大图

人之常情

问题是他在会上骗我说做完了。
已经骗了N次了。。。
现在完全不敢相信他。

作者: planetkeeper 时间: 19-12-2013 14:06

kiluyar 发表于 19-12-2013 12:02

登录/注册后可看大图

刚才鬼佬同事说要提前下班，我告诉他他做的东西有点问题，结果人家一脸不高兴。。。
唉。。。以后不管了

我早就放弃了，做完自己那部分就行了
眼不见为净了

作者: DDD888 时间: 19-12-2013 14:42

planetkeeper 发表于 19-12-2013 14:06

登录/注册后可看大图

我早就放弃了，做完自己那部分就行了
眼不见为净了

9494

作者: DDD888 时间: 19-12-2013 14:44

kiluyar 发表于 19-12-2013 13:48

登录/注册后可看大图

问题是他在会上骗我说做完了。
已经骗了N次了。。。
现在完全不敢相信他。

可能无意的啦,有时以为改正了错误,但会造成其他没测试过的地方出错啦,我写unit testing就是为了防止这个发生,以免给老板留下坏印象

作者: kiluyar 时间: 19-12-2013 15:25

DDD888 发表于 19-12-2013 14:44

登录/注册后可看大图

可能无意的啦,有时以为改正了错误,但会造成其他没测试过的地方出错啦,我写unit testing就是为了防止这个发 ...

唉，我也只能认为是无意的。还能咋样。
不过那哥们可不是出一些bug，就是直接不能用。
这些人简直就是Code Kangaroo，没脑子。

作者: DDD888 时间: 21-12-2013 10:12
I have around 400 unit tests now.

作者: caoglish 时间: 21-12-2013 18:54
讨论那么多Unit Testing，Unit Testing的好处是显而易见的。不过楼主问题重点不是在unit testing上。其实楼主缺乏的是说服他人的能力而已。

老板的工作就是出产品卖钱，如果可以不顾用你，就出产品卖钱，连你都可以不要对吧。或者说如果连开发都不要就出产品，那他最好都不要你去开发。

作为一名合格的程序员，开发技术是一定要的，但是要作为一个优秀的程序员，口才一定要好。一定要有说服人的能力。要有说不的能力，也要有说服他人听你的能力。

我在我工作的地方，有两个contract，他们做出来的产品都是有很多问题的，可以正常运转，但是修改起来更本无从下手。但是当他们来描述他们产品，说服我的领导的时候，都是极具说服力的，能让在场的人都‘明白’这个是唯一的solution。正是他们说服力强，所以吃得开，人人都喜欢他们（不是他们的代码）不说，而且受雇于很多公司。

而我领导，也经常鼓励我去说服他及其说服我们的客户应该怎么做，不管对方喜欢不喜欢，都要说服或者双方妥协出一个折中的方案才好。

就楼主的例子吧，你自己如何证明unit testing是一定需要的，如何说服老板unit testing是一定需要的。

作者: caoglish 时间: 21-12-2013 19:06
另外说说whatever testing。测试的重要性太重要了，自从自己开始做写测试代码后，就真的省力好多，已经习惯了用测试代码去检查产品代码的可靠性了。

没有测试代码如何证明你自己的大部分代码是能正确运行的？，没有测试代码，你如何敢去改进底层核心代码，保证自己的改动不会影响到整个系统的运行？

如果一个现代的软件公司，项目没有自动测试，持续集成，代码质量控制，版本控制，工作流程管理，依赖包管理等，那更本不是一个成熟的IT软件公司，是没有太大前途的。如果楼主真的想在这个行业走的更远，又说服不了自己现在老板去加入这些现代软件开发方式的话，还是赶紧离开现在的公司，去找一个有现代开发方式的软件公司工作才有前途

欢迎光临 FreeOZ论坛 (https://www.freeoz.org/bbs/)