最近看了一下测试驱动方式的介绍文章,感觉这种模式不错。 但不太清楚现在普及到了什么程度。 或者主动写测试用例的时候多不多。
![]() | 1 indooorsman 2016-10-19 22:39:58 +08:00 via Android 不是 |
![]() | 2 airyland 2016-10-19 22:59:21 +08:00 via iPhone 是,商城的代码都必须过一遍测试才敢上线 |
![]() | 3 coa 2016-10-19 23:01:25 +08:00 曾经想尝试下来着,后来发现如果没有一定架构意识,属于想到哪写到哪的这种根本驱动不起来,会出现测试和开发不断两头改的憋屈情形。。还有就是真写起来光测试代码可能不一定比开发代码少多少。。代码量增加可观。。 so 。。。 |
![]() | 4 iyaozhen 2016-10-19 23:12:59 +08:00 via Android 推荐看看王垠的《测试的道理》 http://www.yinwang.org/blog-cn/2016/09/14/tests 不能为了形式而形式。当需求不明确的时候就会出现楼上说的测试代码和业务代码两头一起改的窘态。还是要看公司项目流程 |
![]() | 5 ivvei 2016-10-19 23:19:45 +08:00 不是。其实我尝试过 TDD ,后来发现测试代码的 bug 比要测试的代码的 bug 还多,为了能正确地测试,我得先花很大精力折腾测试代码。回头一看比写了两份代码的工作量还多。然后,需求变了…… |
![]() | 6 guyskk 2016-10-19 23:24:47 +08:00 ![]() 写完一个模块就测一个(自己写测试),测试让我有把握自己的代码就是按我预期的那样运行。 |
![]() | 7 skydiver 2016-10-19 23:26:01 +08:00 都是 PM 驱动开发…… |
8 JhZ7z587cYROBgVQ 2016-10-19 23:34:04 +08:00 在前公司的 web 项目上试过,对接口对模型层啥的做了测试,但是在现公司做得这个项目因为大量操作数据库,实际上很难写单元测试,也就没有用 TDD ,都是先测试环境下冒烟,然后校验数据正确性再去线上灰度最后全量上这种。 |
![]() | 9 enenaaa OP |
![]() | 10 sfree2005 2016-10-19 23:46:14 +08:00 via iPhone 我个人还是倾向测试驱动的。需求不明确的话 的确需要两边一起写或者改。但相对于业务代码来说,写测试代码所花费的时间可以很短 也让整个流程高效了很多 值得的 |
![]() | 11 exoticknight 2016-10-19 23:54:55 +08:00 我认为非常需要,但是基本没试过…… 可能外企会更加着重? |
![]() | 12 Just1n 2016-10-20 00:01:30 +08:00 我厂就是最典型的 TDD 。 |
![]() | 13 czheo 2016-10-20 02:42:56 +08:00 王 yin 说的很对,这么简单的道理,你们怎么就不明白呢? |
![]() | 14 lightening 2016-10-20 04:03:17 +08:00 看情况。我认为这不能一概而论。 对于很简单一看就懂,也不太会变动的东西,我不写测试。 对于比较核心、一旦出错后果严重的代码,我事后写测试。 对于很复杂、写的时候就容易出问题的代码,我做 TDD ,先写测试后写实际代码。 另外出过 bug 的代码我会重新考虑补测试。 我个人不追求 100% 测试覆盖,追求用最小的测试量达到最大的效能。 |
15 df4VW 2016-10-20 06:02:15 +08:00 只写集成测试 |
![]() | 16 doubleflower 2016-10-20 07:59:49 +08:00 基本只写集成测试,除非哪个单元部分很复杂,大部分都是事后写。 设计 API 时可能会打打草稿具体 URL 形式,但那也不会是测试先行。 对于基本不大动或一次性的代码从不写测试,人工测试。 |
![]() | 17 linux40 2016-10-20 08:19:34 +08:00 via Android 一个相对独立的模块完成写吧 |
![]() | 18 ming2050 2016-10-20 08:25:42 +08:00 via iPhone ![]() 我是工资驱动的 |
![]() | 19 qwertyiuop 2016-10-20 09:21:08 +08:00 @mringg +1 |
![]() | 20 g0thic 2016-10-20 09:25:44 +08:00 ![]() deadline 驱动 |
![]() | 22 akring 2016-10-20 09:45:23 +08:00 甲方驱动, TDD 什么的完全不管用, deadline 前一周改设计改需求什么的我们都习惯了 |
![]() | 23 garfieldWu 2016-10-20 09:48:48 +08:00 面向领导编程 |
![]() | 24 garfieldWu 2016-10-20 09:49:41 +08:00 bug 驱动开发,下午茶驱动开发,愧疚感驱动开发 以上。 |
![]() | 25 zongren 2016-10-20 11:49:45 +08:00 正经的开发肯定是 TDD 的,业务耦合紧密的地方可以人工测 |
![]() | 26 bugcode 2016-10-20 12:03:16 +08:00 via iPhone 发布会现场驱动 |
![]() | 27 asj 2016-10-20 13:36:39 +08:00 本想说王喷子懂个 p 的 TDD ,读了一遍发现还是挺懂的。:) 不过他那 12 条里除第 3 条和半个第 7 条外都和 TDD 没什么冲突。 |
![]() | 28 xAI 2016-10-20 13:44:35 +08:00 TDD + SELENIUM |
![]() | 29 adv007 2016-10-20 14:47:13 +08:00 via iPhone bdd 老板的行为驱动开发 |
30 feiyuanqiu 2016-10-24 18:04:08 +08:00 |