问下你们是怎么写单元测试的？

[chenqh]

我现在还是手工测. 因为

1.  没人带单元测试
2.  单元测试无法自动化，不能自动建表，而且搞模拟数据很耗时间
3. 写起来麻烦，一个 function 如果有 100 行左右的代码，测试代码估计要 1K 行，
而且如果逻辑改了的话。测试代码要改 N 久

[ansheng]

django 有 tests ，来拥抱 django 把。

[wweir]

数据库建好，放 docker 里

[kinghui]

我们的解决方案是两个数据库:

- 正常开发库
- 测试库

跑单元测试之前把开发库的表结构拷贝到测试库, 然后自动扫描测试包下的 SQL 文件并在测试数据库执行(测试数据初始化).

缺点就是每次运行测试之前会有比较长的数据库初始化时间, 但可以接受.

[asj]

你没发现看起来是单元测试的问题，换个角度其实是被测代码的问题么？

[vicalloy]

你可以参考一下， GitHub 上的开源项目，很少是不带单元测试的。
另外如果你觉得单元测试很难写，有可能是你的设计有问题，模块间的耦合太重。

另外单元测试写到什么程度本来就没有一个很明确的界定。
对我来说，一些核心模块会写单元测试，业务模块大多不写。
核心模块不会频繁改动，且被广泛引用，出问题影响大。
业务模块影响范围小，而且需求变动很可能导致所有测试用例都得重写，测试用例的性价比太低。
（注： REST 接口都会写测试用例。 REST 自动化测试比手动测试还更简单）

[jacsice]

pytest

[zpfhbyx]

- -，基本没写过！

[Wichna]

代码最好分层， models 、 service 、 controller 三层，分层测试。如果是 python 的话推荐用 pytest ，测试数据库用 sqlite 就够了。
每次 push 之后触发持续集成然后跑单元测试！都是自动化的。

[IanPeverell]

web ，因为前后端分离，所以可以直接请求 API ，一个是看返回状态，一个是看返回的数据结构，数据内容是数据库的问题所以不在考虑范围

[googlebot]

从来不写，

[carlonelong]

def testXXX
#TODO
pass