planetkeeper 发表于 11-12-2013 13:19 static/image/common/back.gif
恭喜涨薪水
谢谢
我的目标是年收入十五万新西兰元,理想的话能达到二十万新西兰元更好,但如果能自己有项目,自己作老板那就更好了:lol
本帖最后由 DDD888 于 11-12-2013 14:21 编辑
ericvan76 发表于 11-12-2013 10:01 static/image/common/back.gif
写unit test不是挑战，
写最少的unit test，出最高质量的代码才是挑战。
那就变得说不清了,我的目标是maintainability index 在80以上,能用最少的代码来完成项目,如果不写代码能做到同样的效果那就更好了:congra代码要同时支持上万个concurrent connection,速度运行要飞快,时刻作benchmark:loveliness:
DDD888 发表于 11-12-2013 12:20 static/image/common/back.gif
那就变得说不清了,我的目标是maintainability index 在80以上,能用最少的代码来完成项目,如果不写代码能 ...
你没懂我的意思
Samantabhadra 发表于 11-12-2013 14:38 static/image/common/back.gif
这帖子的讨论感觉很怪，新出来跑江湖的？
看不懂你想说的意思?
ericvan76 发表于 11-12-2013 14:31 static/image/common/back.gif
你没懂我的意思
啥意思?
DDD888 发表于 11-12-2013 12:56 static/image/common/back.gif
啥意思?
我不是说不写test或者少写test，我说的是生产力的问题，这东西说来话长，现在没空说。
就算不是TDD，unit test的好处不用多言，不过这好处很多都只是从程序员角度而言，换句话说就是干活容易了
high unit test coverage的项目，维护起来要轻松不少，特别是长期项目，相比之下改点小东西把别的地方搞爆了的可能性比较小一些，最起码也是peace of mind
但是从老板的角度，这里头有没有价值产出就未必了（起码短期如此），好的测试框架花的人月，恐怕比写code都少不到哪去
当然日后加feature改bug一不小心把哪里弄挂了还是你的责任就是了
这世道就是又要马儿跑又要少吃草 :Q
DDD888 发表于 11-12-2013 05:23 static/image/common/back.gif
是的,这正是我想做的
我是用http://qunitjs.com/ 做javascript unit testing的,很简单的:loveliness ...
我们也是用QUnit。
你可以写个简单的script，用来跑Qunit。就可以像你的webdriver一样，自动化了。
然后用个bamboo之类的build server。老板不给钱的话，就弄个jenkins之类的免费的也行。
每次有commit，就自动跑测试，junit/qunit/webdriver都自动跑。
对于regression很有帮助。对于增加自己对程序质量的信心也很有帮助。
唯一的坏处，就是对老板太有好处了。他想换掉你的时候，需要考虑的因素少了好几个。估计只要考虑把source control跟build server这两个东西抓在手里就行了。;P
真不明白你老板是怎么想的。这种对他这么有利的事情，居然还阻止你去做。:L
planetkeeper 发表于 11-12-2013 08:40 static/image/common/back.gif
正儿八经搞unit test，selenium test automation，都是全职的活。。。
你一个全包，这你也能忍。。。
test本来就是开发的一部分，只是有些人喜欢手动测试而已。
unit test跟webdriver test，刚开始需要做一些基本的工作，设置好了，每次再加test case就不算太麻烦。
black_zerg 发表于 11-12-2013 08:48 static/image/common/back.gif
能卖钱就是好代码。unit testing 不是java的传统么，js也要了？ 我是从来对TDD不以为然的，反生产力，不过只 ...
写test不一定就是TDD。反不反生产力也很难说。
一次性的卖钱，跟连续卖钱，也是有区别的。
只是一次性卖一个看起来可以跑的程序，可能就不太需要test。
DDD888 发表于 11-12-2013 09:06 static/image/common/back.gif
没办法了,老板说要让我100%保证修改后没有错误,只能用最好的技术来做啦,公司里没有测试人员,就靠老板和 ...
手机的自动化测试还没做过。据说android的比iphone的要好很多。
不过最少服务器方面的api应该是可以做到自动化测试的。
身为文科生兼电脑半文盲，看着一群的牛人在讨论写程序真是云里雾里:L
cais 发表于 11-12-2013 23:14 static/image/common/back.gif
test本来就是开发的一部分，只是有些人喜欢手动测试而已。
unit test跟webdriver test，刚开始需要做一些 ...
我以前就做过测试自动化，维护test automation framework并不是那么简单的
这不比code base，尤其是web应用，feature update的频率很快
测试framework一旦没人维护，很快就不能满足QA的需求了
要不然也不会有公司100k招聘test automation specialist了
DDD888 发表于 11-12-2013 14:18 static/image/common/back.gif
谢谢
我的目标是年收入十五万新西兰元,理想的话能达到二十万新西兰元更好,但如果能自己有项目,自己作老 ...
对头，既然你现在就是one man army的话，为啥不自己做呢
planetkeeper 发表于 12-12-2013 08:37 static/image/common/back.gif
对头，既然你现在就是one man army的话，为啥不自己做呢
不知道做啥项目?
black_zerg 发表于 12-12-2013 07:35 static/image/common/back.gif
http://programmers.stackexchange.com/questions/98485/tdd-negative-experience. 简单说你时间有限，如何 ...
我写了两百多个unit test, 找到了两个bug,但实际应用中这两个bug根本就不会遇到,当然我假设我做的unit test还是取得了成果,找到了两个bug:congra
本帖最后由 ericvan76 于 12-12-2013 09:10 编辑
DDD888 发表于 12-12-2013 07:34 static/image/common/back.gif
我写了两百多个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说的，如果你把时间用在学习或者思考架构优化上，那么就有减少局限性的可能。
black_zerg 发表于 12-12-2013 09:49 static/image/common/back.gif
spot on 所以你这两百多用例的产出就是发现了这两个实际根本不会发生的bug，这个时间也许不如用在学习或者思 ...
勿以善小而不为,unit test相当于有一个人一直在peer review code change,好处是不可估量的
DDD888 发表于 12-12-2013 11:09 static/image/common/back.gif
勿以善小而不为,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可是看得见摸得着的。澳洲缺少做产品的公司，这方面也是一个劣势
见仁见智。架构上设计上的问题，当然要考虑。但是那跟写不定test没有太大关系。
现在讨论得比较多的unit test，是相对于一个小模块，一个个小class而言的。架构再怎么好，也要保证小的地方实现是正确的。
前面有人说好的程序员是边写边测。如果那些“边测”是手动做的话，
过了一段时间想改一点东西，就要重新手动去测以前测过的东西。大部份人应该都不会那样做的。造成的结果就是只测一部份关键的地方。
这样就很容易出现bug。如果以前多花一点时间把边写边测的那些test都变得自动化了，以后改动起来信心就大很多了。
另外，testing不只是unit test。还有integration test, webdriver test, performance test等等。
前几天，我就碰到被performance test发现了我弄出来的一个bug。那个pull request是经过三个senior developers review过的。:L
今天我们做restrospective的时候，同事们纷纷表示前一段时间花也好久做这个performance test是值得的。
我觉得test是维护你的系统的一种手段。当系统变得很大的时候，手动的手段就显得行不太通，因为不scalable。
所以现在这种自动化测试，continuous integration, continuous deployment之类的东西才会比较流行。
test写得好，跟架构设计那些东西是没有冲突。如果你要改动架构，没有integration test的话，很难保证改了之后不会出问题。
没有performance test，怎么知道改了之后性能没有降低。
以上是我这几个月在新公司被洗脑之后的结果。。。:s2
仅供大家参考。
我给自己设立了一个规定,新改的程序都要写unit test, 如果有空的话,逐渐给legacy code加unit test:victory:
black_zerg 发表于 12-12-2013 21:50 static/image/common/back.gif
关键在于需求不断变化,很多公司是做系统不是做产品。而且写那种处处mock的测试真是枯燥无比，最后还是不能替 ...
顺便问一下,我本来都是用StrictMock的,后来书上说DynamicMock好,我就用了DynamicMock,后来又读到Stub好,现在都用Stub,我发觉原来用StrictMock改成Stub,那些测试也都通过了,StrictMock和Stub有啥区别啊?我是用Rhino.Mocks
one man army应付小项目还可以，大的项目我无法想象怎么可能一个人做的过来
我也很难想象习惯了TDD，continuous integration的人，会愿意回归到原始的waterfall。。。
planetkeeper 发表于 13-12-2013 08:46 static/image/common/back.gif
one man army应付小项目还可以，大的项目我无法想象怎么可能一个人做的过来
我也很难想象习惯了TDD，conti ...
啥是小项目,啥是大项目?:lol
根据需要决定是否要写Unit Test。
cais 发表于 11-12-2013 23:12 static/image/common/back.gif
我们也是用QUnit。
你可以写个简单的script，用来跑Qunit。就可以像你的webdriver一样，自动化了。
然后 ...
我写的unit test :)
namespace UnitTest.Qunit
{
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using OpenQA.Selenium.Firefox;
public class UnitTestQunit
{
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();
}
}
}