我就问一下大家写代码都是测试驱动吗

[enenaaa]

最近看了一下测试驱动方式的介绍文章，感觉这种模式不错。 但不太清楚现在普及到了什么程度。 或者主动写测试用例的时候多不多。

[indooorsman]

不是

[airyland]

是，商城的代码都必须过一遍测试才敢上线

[coa]

曾经想尝试下来着，后来发现如果没有一定架构意识，属于想到哪写到哪的这种根本驱动不起来，会出现测试和开发不断两头改的憋屈情形。。还有就是真写起来光测试代码可能不一定比开发代码少多少。。代码量增加可观。。 so 。。。

[iyaozhen]

推荐看看王垠的《测试的道理》 http://www.yinwang.org/blog-cn/2016/09/14/tests
不能为了形式而形式。当需求不明确的时候就会出现楼上说的测试代码和业务代码两头一起改的窘态。还是要看公司项目流程

[ivvei]

不是。其实我尝试过 TDD ，后来发现测试代码的 bug 比要测试的代码的 bug 还多，为了能正确地测试，我得先花很大精力折腾测试代码。回头一看比写了两份代码的工作量还多。然后，需求变了……

[guyskk]

写完一个模块就测一个（自己写测试），测试让我有把握自己的代码就是按我预期的那样运行。

[skydiver]

都是 PM 驱动开发……

[jason0916]

在前公司的 web 项目上试过，对接口对模型层啥的做了测试，但是在现公司做得这个项目因为大量操作数据库，实际上很难写单元测试，也就没有用 TDD ，都是先测试环境下冒烟，然后校验数据正确性再去线上灰度最后全量上这种。

[enenaaa]

@iyaozhen 倒不是形式， 这一段在写脚本代码。重构的时候比较痛苦，连语法正确都不能保证。如果有完善的测试用例那就方便多了。

@guyskk 测试当然都会测试。但你是先写测试用例再写代码呢， 还是先写代码再测试。用例会不会保留下来归入用例集。

@ivvei 有些功能写测试很麻烦，而且容易产生 bug ， 比如 UI 界面。 我就有点担心你说的情况。

[sfree2005]

我个人还是倾向测试驱动的。需求不明确的话 的确需要两边一起写或者改。但相对于业务代码来说，写测试代码所花费的时间可以很短 也让整个流程高效了很多 值得的

[exoticknight]

我认为非常需要，但是基本没试过……
可能外企会更加着重？

[Just1n]

我厂就是最典型的 TDD 。

[czheo]

王 yin 说的很对，这么简单的道理，你们怎么就不明白呢？

[lightening]

看情况。我认为这不能一概而论。

对于很简单一看就懂，也不太会变动的东西，我不写测试。
对于比较核心、一旦出错后果严重的代码，我事后写测试。
对于很复杂、写的时候就容易出问题的代码，我做 TDD ，先写测试后写实际代码。

另外出过 bug 的代码我会重新考虑补测试。

我个人不追求 100% 测试覆盖，追求用最小的测试量达到最大的效能。

[df4VW]

只写集成测试

[doubleflower]

基本只写集成测试，除非哪个单元部分很复杂，大部分都是事后写。

设计 API 时可能会打打草稿具体 URL 形式，但那也不会是测试先行。

对于基本不大动或一次性的代码从不写测试，人工测试。

[linux40]

一个相对独立的模块完成写吧

[mringg]

我是工资驱动的

[stnaw]

@mringg +1

[g0thic]

deadline 驱动