如果老板不同意我花时间写unit testing,该如何办啊?

DDD888

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

                               
登录/注册后可看大图

恭喜涨薪水

谢谢

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

DDD888

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

                               
登录/注册后可看大图

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

那就变得说不清了,我的目标是maintainability index 在80以上,能用最少的代码来完成项目,如果不写代码能做到同样的效果那就更好了代码要同时支持上万个concurrent connection,速度运行要飞快,时刻作benchmark

艾瑞克

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

                               
登录/注册后可看大图

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

你没懂我的意思

阿贞

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

DDD888

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

                               
登录/注册后可看大图

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

看不懂你想说的意思?

DDD888

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

                               
登录/注册后可看大图

你没懂我的意思

啥意思?

艾瑞克

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

                               
登录/注册后可看大图

啥意思?

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

Daibaw

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

cais

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

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

                               
登录/注册后可看大图

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

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

cais

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

                               
登录/注册后可看大图

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

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

cais

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

                               
登录/注册后可看大图

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

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

美羽mm

身为文科生兼电脑半文盲，看着一群的牛人在讨论写程序真是云里雾里

black_zerg

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

planetkeeper

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

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

                               
登录/注册后可看大图

谢谢

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

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

DDD888

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

                               
登录/注册后可看大图

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

不知道做啥项目?

DDD888

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

                               
登录/注册后可看大图

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

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

black_zerg

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

艾瑞克

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

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

                               
登录/注册后可看大图

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

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

Daibaw

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

见仁见智。架构上设计上的问题，当然要考虑。但是那跟写不定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

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

DDD888

我给自己设立了一个规定,新改的程序都要写unit test, 如果有空的话,逐渐给legacy code加unit test

DDD888

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

                               
登录/注册后可看大图

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

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

planetkeeper

one man army应付小项目还可以，大的项目我无法想象怎么可能一个人做的过来
我也很难想象习惯了TDD，continuous integration的人，会愿意回归到原始的waterfall。。。

DDD888

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

                               
登录/注册后可看大图

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

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

羊头党

根据需要决定是否要写Unit Test。

DDD888

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();
        }
    }
}