f*****w
发帖数: 2602 | 1 不知道现在的best practise 是什么
是把REST API和db 放一起测试 还是分开测试然后mock所有的数据库操作 ？
google了下好像说什么的都有
有什么好用的包或什么的吗？
非常感谢哈 |
p*****2
发帖数: 21240 | 2 mock也挺麻烦的
我们是一起测
【在 f*****w 的大作中提到】
: 不知道现在的best practise 是什么
: 是把REST API和db 放一起测试 还是分开测试然后mock所有的数据库操作 ？
: google了下好像说什么的都有
: 有什么好用的包或什么的吗？
: 非常感谢哈
|
f*****w
发帖数: 2602 | 3 i c
维护两个数据库每次要连不同的也挺啰嗦
有什么好的lib可以让这个过程稍微方便些的吗
【在 p*****2 的大作中提到】
: mock也挺麻烦的
: 我们是一起测
|
p*****2
发帖数: 21240 | 4 设一个环境变量
production staging 和dev
每个环境设置不同
【在 f*****w 的大作中提到】
: i c
: 维护两个数据库每次要连不同的也挺啰嗦
: 有什么好的lib可以让这个过程稍微方便些的吗
|
l**********n
发帖数: 8443 | 5 rest主要是测试route。database测试的是table，index， schema这些。database容易
测。route需要个环境。用swagger的会比较好
【在 f*****w 的大作中提到】
: 不知道现在的best practise 是什么
: 是把REST API和db 放一起测试 还是分开测试然后mock所有的数据库操作 ？
: google了下好像说什么的都有
: 有什么好用的包或什么的吗？
: 非常感谢哈
|
d****n
发帖数: 1637 | 6 an example of using mocha unittest framework
https://github.com/bredikhin/sailsjs-mocha-testing-barrels-fixtures-example
【在 f*****w 的大作中提到】
: 不知道现在的best practise 是什么
: 是把REST API和db 放一起测试 还是分开测试然后mock所有的数据库操作 ？
: google了下好像说什么的都有
: 有什么好用的包或什么的吗？
: 非常感谢哈
|
g*****g
发帖数: 34805 | 7 That's not the right way to do unit test, it's for end-to-end test. Mock or
in-memory DB is the right way for unit test.
【在 p*****2 的大作中提到】
: mock也挺麻烦的
: 我们是一起测
|
l**********n
发帖数: 8443 | 8 mongo非常好测试。
or
【在 g*****g 的大作中提到】
: That's not the right way to do unit test, it's for end-to-end test. Mock or
: in-memory DB is the right way for unit test.
|
g*****g
发帖数: 34805 | 9 It's not about if a DB is easy to test. It's about if end to end test can
replace unit test. And the simple answer is no. Recently there's a nice blog
on this.
http://googletesting.blogspot.com/2015/04/just-say-no-to-more-e
【在 l**********n 的大作中提到】
: mongo非常好测试。
:
: or
|
p*****2
发帖数: 21240 | 10
or
这个您老就不用操心了。测试完全是根据需要来的。没有什么right way。
【在 g*****g 的大作中提到】
: That's not the right way to do unit test, it's for end-to-end test. Mock or
: in-memory DB is the right way for unit test.
|
|
|
g*****g
发帖数: 34805 | 11 Of course it's not my problem, but these are the best practices in the
industry, and it's a fundamental one.
【在 p*****2 的大作中提到】
:
: or
: 这个您老就不用操心了。测试完全是根据需要来的。没有什么right way。
|
p*****2
发帖数: 21240 | 12
其实也难说，真的。G是很强调这个，但是也是非难断。测试每家公司差别也是蛮大的。
我更愿意通过engineer的quality和code review来解决quality的问题。
【在 g*****g 的大作中提到】
: Of course it's not my problem, but these are the best practices in the
: industry, and it's a fundamental one.
|
p*****2
发帖数: 21240 | 13 对了 大牛你家跟google一个路子？
【在 g*****g 的大作中提到】
: Of course it's not my problem, but these are the best practices in the
: industry, and it's a fundamental one.
|
g*****g
发帖数: 34805 | 14 It's not a G recommendation, it's a well known practice in the industry. It'
s up to individual team to do what they want to do, but I always recommend
best practices with reasons.
的。
【在 p*****2 的大作中提到】
: 对了 大牛你家跟google一个路子？
|
p*****2
发帖数: 21240 | 15 经常unit test没问题 integration就不work了
It'
【在 g*****g 的大作中提到】
: It's not a G recommendation, it's a well known practice in the industry. It'
: s up to individual team to do what they want to do, but I always recommend
: best practices with reasons.
:
: 的。
|
l**********n
发帖数: 8443 | 16 unit test又不能测试interaction. 比如oauth, session.
【在 p*****2 的大作中提到】
: 经常unit test没问题 integration就不work了
:
: It'
|
g*****g
发帖数: 34805 | 17 It's not one or the other, you need both.
【在 p*****2 的大作中提到】
: 经常unit test没问题 integration就不work了
:
: It'
|
p*****2
发帖数: 21240 | 18
都搞iteration太慢了,很多公司受不了
【在 g*****g 的大作中提到】
: It's not one or the other, you need both.
|
g*****g
发帖数: 34805 | 19 I am not gonna lecture the importance of unit test here. Quality and
quantity is always a tradeoff.
【在 p*****2 的大作中提到】
:
: 都搞iteration太慢了,很多公司受不了
|
w**z
发帖数: 8232 | 20 Here is what I do, I write integration tests for the rest services, using
Jersey test framework, https://jersey.java.net/documentation/latest/test-
framework.html
There are few reasons I do that
1) The service I am writing normally is micro service, so running a full
round of integration tests won't take more than a few minutes.
2) I can run them locally before I push my commits, so bugs can be
identified quickly and thus fixed quickly
3) Jenkins job also runs those tests, so again it's not likely the major
bugs will be there when we release the service to QA
4) For our team, there is no dedicated QA. I simply don't have time to write
both unit tests and integration tests.
【在 g*****g 的大作中提到】
: I am not gonna lecture the importance of unit test here. Quality and
: quantity is always a tradeoff.
|
|
|
g*****g
发帖数: 34805 | 21 The pitfalls here are that
1. It may not be easy to identify the bug when integration test fails,
especially if you didn't write the code in the first place. You are coupling
data, other services dependencies and your code in your test. That makes
the debugging process longer than it can be with unit tests. Unit tests won'
t catch all your bugs, but it can catch most of your bugs.
2. And integration tests can typically cover happy path, not much on corner
cases. And if you try to cover corner cases, it starts getting too long to
run your build. Yet corner cases always hit in production.
Again, it's a tradeoff, we all cut corners where we have to, I am just
talking about industry best practice which typically favors quality over
quantity.
【在 w**z 的大作中提到】
: Here is what I do, I write integration tests for the rest services, using
: Jersey test framework, https://jersey.java.net/documentation/latest/test-
: framework.html
: There are few reasons I do that
: 1) The service I am writing normally is micro service, so running a full
: round of integration tests won't take more than a few minutes.
: 2) I can run them locally before I push my commits, so bugs can be
: identified quickly and thus fixed quickly
: 3) Jenkins job also runs those tests, so again it's not likely the major
: bugs will be there when we release the service to QA
|
t*******h
发帖数: 2882 | 22 译文出来了
对更多的「端到端测试」说不
http://article.yeeyan.org/view/66324/453360
貌似所有书本上都要求UT不依赖包括数据库在内的任何外部dependency。实际操作中很
多公司都用test DB。
blog
【在 g*****g 的大作中提到】
: It's not a G recommendation, it's a well known practice in the industry. It'
: s up to individual team to do what they want to do, but I always recommend
: best practices with reasons.
:
: 的。
|
p*****2
发帖数: 21240 | 23
真想测的纯就应该上FP和Monad
【在 t*******h 的大作中提到】
: 译文出来了
: 对更多的「端到端测试」说不
: http://article.yeeyan.org/view/66324/453360
: 貌似所有书本上都要求UT不依赖包括数据库在内的任何外部dependency。实际操作中很
: 多公司都用test DB。
:
: blog
|
w**z
发帖数: 8232 | 24 In most of the cases, it's a wishful thinking. I an simply not given enough
time to mock all the outside dependencies. As goodbug said, it's all about
tradeoff, that is the choice as an organization you need to make.
【在 t*******h 的大作中提到】
: 译文出来了
: 对更多的「端到端测试」说不
: http://article.yeeyan.org/view/66324/453360
: 貌似所有书本上都要求UT不依赖包括数据库在内的任何外部dependency。实际操作中很
: 多公司都用test DB。
:
: blog
|
n******n
发帖数: 12088 | 25 围观的感觉 ，好虫的回答堂堂正正，你老怎么东一榔头，西一棒子，总扯些不着边际
的东西。
【在 p*****2 的大作中提到】
:
: 真想测的纯就应该上FP和Monad
|
p*****2
发帖数: 21240 | 26 textbook上的东西最容易讲
【在 n******n 的大作中提到】
: 围观的感觉 ，好虫的回答堂堂正正，你老怎么东一榔头，西一棒子，总扯些不着边际
: 的东西。
|
n******n
发帖数: 12088 | 27 能上教科书显然有它的道理。
【在 p*****2 的大作中提到】
: textbook上的东西最容易讲
|
p*****2
发帖数: 21240 | 28 那你找本书看就行了
【在 n******n 的大作中提到】
: 能上教科书显然有它的道理。
|
n******n
发帖数: 12088 | 29 那还要学校干啥？一人发一套教科书即可。
【在 p*****2 的大作中提到】
: 那你找本书看就行了
|
p*****2
发帖数: 21240 | 30
为什么new grad找工作难？
【在 n******n 的大作中提到】
: 那还要学校干啥？一人发一套教科书即可。
|
|
|
n******n
发帖数: 12088 | 31 你怎么总离题？
【在 p*****2 的大作中提到】
:
: 为什么new grad找工作难？
|
p*****2
发帖数: 21240 | 32
因为纸上谈兵没意思。
【在 n******n 的大作中提到】
: 你怎么总离题？
|
n******n
发帖数: 12088 | 33 土法炼钢更可怕
【在 p*****2 的大作中提到】
:
: 因为纸上谈兵没意思。
|
g*********e
发帖数: 14401 | 34 放在一起的叫integration trst
【在 f*****w 的大作中提到】
: 不知道现在的best practise 是什么
: 是把REST API和db 放一起测试 还是分开测试然后mock所有的数据库操作 ？
: google了下好像说什么的都有
: 有什么好用的包或什么的吗？
: 非常感谢哈
|
g*****g
发帖数: 34805 | 35 A bug cost 1 to be found and fixed by dev, 10 to be found by QA, and at
least 100 to be found by customer, just think about the communication costs,
let alone implicit churn.
So while unit test is against intuition for agile development, it's cost-
effective for services that will be maintained for years. I found front end
engineers are less used to unit tests. For one it's harder to do, for two
many of them are used to manual testing. |
L***s
发帖数: 1148 | 36 在我们组，integration tests的主要目的有两个：
一是做文档用。需求每周都在变，没人专门写文档的，
integration tests本身是最好的文档。
二是保护自己写的feature不被后来人无意破坏。
就算是尽量解耦合的系统，也有公共的耦合之处，
我写的integration tests要保证当后来人的修改
破坏了我写的东西时，他被告之他踩到了我的脚，
从而尽量减少regressions的发生。 |
p*****2
发帖数: 21240 | 37
costs,
end
unit test只是保证quality的其中一种办法，而且是最不重要的一种办法。
【在 g*****g 的大作中提到】
: A bug cost 1 to be found and fixed by dev, 10 to be found by QA, and at
: least 100 to be found by customer, just think about the communication costs,
: let alone implicit churn.
: So while unit test is against intuition for agile development, it's cost-
: effective for services that will be maintained for years. I found front end
: engineers are less used to unit tests. For one it's harder to do, for two
: many of them are used to manual testing.
|
n******n
发帖数: 12088 | 38 有哪些办法？重要性排序依次是？
【在 p*****2 的大作中提到】
:
: costs,
: end
: unit test只是保证quality的其中一种办法，而且是最不重要的一种办法。
|
n******n
发帖数: 12088 | 39 需求每周变，测试也每周变？
【在 L***s 的大作中提到】
: 在我们组，integration tests的主要目的有两个：
: 一是做文档用。需求每周都在变，没人专门写文档的，
: integration tests本身是最好的文档。
: 二是保护自己写的feature不被后来人无意破坏。
: 就算是尽量解耦合的系统，也有公共的耦合之处，
: 我写的integration tests要保证当后来人的修改
: 破坏了我写的东西时，他被告之他踩到了我的脚，
: 从而尽量减少regressions的发生。
|
g*****g
发帖数: 34805 | 40 你是错的，理由书上都说得很清楚。也没见你有啥有力的反驳。Cut corner是一回事，
Cut corner还给别人推荐就不合适。
【在 p*****2 的大作中提到】
:
: costs,
: end
: unit test只是保证quality的其中一种办法，而且是最不重要的一种办法。
|
|
|
p*****2
发帖数: 21240 | 41
1. architecture (system design)
2. software design
3. quality of SDE
4. quality of implementation
5. code review
以上几个都比unit test重要性更高。这也是为什么这几年top公司选材非常看重bug
free。
【在 n******n 的大作中提到】
: 有哪些办法？重要性排序依次是？
|
n******n
发帖数: 12088 | 42 架构是普通工程师能决定的？
2/3/4/5全和unit test有关。不好写测试的设计不是好设计。不会写测试的SDE质量不
会高。不写测试无法保证实现质量。代码审核一项重要任务就是审核测试。
【在 p*****2 的大作中提到】
:
: 1. architecture (system design)
: 2. software design
: 3. quality of SDE
: 4. quality of implementation
: 5. code review
: 以上几个都比unit test重要性更高。这也是为什么这几年top公司选材非常看重bug
: free。
|
p*****2
发帖数: 21240 | 43
那是你的理解。
【在 n******n 的大作中提到】
: 架构是普通工程师能决定的？
: 2/3/4/5全和unit test有关。不好写测试的设计不是好设计。不会写测试的SDE质量不
: 会高。不写测试无法保证实现质量。代码审核一项重要任务就是审核测试。
|
g*****g
发帖数: 34805 | 44 You can hire the best engineers in the world and they'd still make mistakes,
it's human nature.
【在 p*****2 的大作中提到】
:
: 那是你的理解。
|
f*****w
发帖数: 2602 | 45 我也觉得那些照着书说的要如何如何如何分开测得全是扯淡 。做测试是为了没有bug，
而不是为了“有测试”，基于这一点，只有适合的测试方法，没有绝对正确的测试方法
不过我现在也碰到很现实的问题，我用test db 来写测试。但是貌似mocha默认就是并
行跑多个测试 互相冲突。。。 当然完全并行就能解决问题（虽然暂时还没明白mocha
下面怎么做），但是真要这样每次跑测试的效率真的会很低啊。。。 我的开发机器8个
core就全浪费了 有啥好的建议没有？
【在 p*****2 的大作中提到】
: mock也挺麻烦的
: 我们是一起测
|
n******n
发帖数: 12088 | 46 书上那些说法是前人的经验总结。理论来自于实践，反过来又指导实践。
要求有测试可以降低出现bug的概率，就像要求统一代码风格可以降低代码审核成本一
样。这都是很好的工程原则。
哪怕你牛到逆天，一个人能完成一个项目，以后代码就不需要别人维护了？
mocha
【在 f*****w 的大作中提到】
: 我也觉得那些照着书说的要如何如何如何分开测得全是扯淡 。做测试是为了没有bug，
: 而不是为了“有测试”，基于这一点，只有适合的测试方法，没有绝对正确的测试方法
: 不过我现在也碰到很现实的问题，我用test db 来写测试。但是貌似mocha默认就是并
: 行跑多个测试 互相冲突。。。 当然完全并行就能解决问题（虽然暂时还没明白mocha
: 下面怎么做），但是真要这样每次跑测试的效率真的会很低啊。。。 我的开发机器8个
: core就全浪费了 有啥好的建议没有？
|
p*****2
发帖数: 21240 | 47
我在测试领域太多年了，我的经验就是前人的经验。
【在 n******n 的大作中提到】
: 书上那些说法是前人的经验总结。理论来自于实践，反过来又指导实践。
: 要求有测试可以降低出现bug的概率，就像要求统一代码风格可以降低代码审核成本一
: 样。这都是很好的工程原则。
: 哪怕你牛到逆天，一个人能完成一个项目，以后代码就不需要别人维护了？
:
: mocha
|
p*****2
发帖数: 21240 | 48
mocha
我是用jasmine测的，不太清楚你的case。你说的并行冲突是什么意思？db那里冲突？
【在 f*****w 的大作中提到】
: 我也觉得那些照着书说的要如何如何如何分开测得全是扯淡 。做测试是为了没有bug，
: 而不是为了“有测试”，基于这一点，只有适合的测试方法，没有绝对正确的测试方法
: 不过我现在也碰到很现实的问题，我用test db 来写测试。但是貌似mocha默认就是并
: 行跑多个测试 互相冲突。。。 当然完全并行就能解决问题（虽然暂时还没明白mocha
: 下面怎么做），但是真要这样每次跑测试的效率真的会很低啊。。。 我的开发机器8个
: core就全浪费了 有啥好的建议没有？
|
g*****g
发帖数: 34805 | 49 这就是unit test的好处之一，mock也好，in memory DB也好可以做到完全独立。如果
有大量的Unit test，就不需要那么多的integration test。整个build就快，发现bug
也快。continuous delivery的必要条件之一。
mocha
【在 f*****w 的大作中提到】
: 我也觉得那些照着书说的要如何如何如何分开测得全是扯淡 。做测试是为了没有bug，
: 而不是为了“有测试”，基于这一点，只有适合的测试方法，没有绝对正确的测试方法
: 不过我现在也碰到很现实的问题，我用test db 来写测试。但是貌似mocha默认就是并
: 行跑多个测试 互相冲突。。。 当然完全并行就能解决问题（虽然暂时还没明白mocha
: 下面怎么做），但是真要这样每次跑测试的效率真的会很低啊。。。 我的开发机器8个
: core就全浪费了 有啥好的建议没有？
|
L***s
发帖数: 1148 | 50 mocha下可以把integration tests分成几个splits，并行跑
mocha
【在 f*****w 的大作中提到】
: 我也觉得那些照着书说的要如何如何如何分开测得全是扯淡 。做测试是为了没有bug，
: 而不是为了“有测试”，基于这一点，只有适合的测试方法，没有绝对正确的测试方法
: 不过我现在也碰到很现实的问题，我用test db 来写测试。但是貌似mocha默认就是并
: 行跑多个测试 互相冲突。。。 当然完全并行就能解决问题（虽然暂时还没明白mocha
: 下面怎么做），但是真要这样每次跑测试的效率真的会很低啊。。。 我的开发机器8个
: core就全浪费了 有啥好的建议没有？
|
|
|
h*****a
发帖数: 1718 | 51 你们这么干production里面bug的情况怎么样？感觉系统大了还是要有更系统的测试
方法，如果只靠人的素质有的时候是很难scale的。
【在 p*****2 的大作中提到】
:
: mocha
: 我是用jasmine测的，不太清楚你的case。你说的并行冲突是什么意思？db那里冲突？
|
n******n
发帖数: 12088 | 52 你牛，一个人的经验顶别人十个。
【在 p*****2 的大作中提到】
:
: mocha
: 我是用jasmine测的，不太清楚你的case。你说的并行冲突是什么意思？db那里冲突？
|
g*****g
发帖数: 34805 | 53 这个事情是不用说的。项目一大，人一多，日子一长，人员变换，再大牛也不见得能知
道别人的代码在干啥。测试覆盖率高低决定了项目的可维护性。
【在 h*****a 的大作中提到】
: 你们这么干production里面bug的情况怎么样？感觉系统大了还是要有更系统的测试
: 方法，如果只靠人的素质有的时候是很难scale的。
|
n******n
发帖数: 12088 | 54 还是见过读代码飞快的牛人，很犀利。不过让牛人干擦屁股的活太浪费了。
【在 g*****g 的大作中提到】
: 这个事情是不用说的。项目一大，人一多，日子一长，人员变换，再大牛也不见得能知
: 道别人的代码在干啥。测试覆盖率高低决定了项目的可维护性。
|
g*****g
发帖数: 34805 | 55 不要迷信大牛，大牛也是人。而且，如果全靠大牛的话，大牛走了不就死菜了。
【在 n******n 的大作中提到】
: 还是见过读代码飞快的牛人，很犀利。不过让牛人干擦屁股的活太浪费了。
|
p*****2
发帖数: 21240 | 56 确实
所以micro service是很好的
我们小team 做的都是micro service
scale确实会是问题 不过我们还没那么大 就是几个人的team
【在 h*****a 的大作中提到】
: 你们这么干production里面bug的情况怎么样？感觉系统大了还是要有更系统的测试
: 方法，如果只靠人的素质有的时候是很难scale的。
|
p*****2
发帖数: 21240 | 57 我的意思是具体工作起来是灵活的 没有一定的章法可遵循
什么都不能走极端 都是根据实际需要分配资源 包括人力 时间 测试 等等
能够合理分配并不容易 比你用教科书要复杂多了 很多tradeoff要考虑
你去看看每家公司的测试理念都有区别
【在 n******n 的大作中提到】
: 你牛，一个人的经验顶别人十个。
|
j********x
发帖数: 2330 | 58 大多数时候你所谓的需要其实大部分也是自己拍脑袋想的
best practice说白了就是让你不需要经过细致分析就能做到eliminate大多数可能出现
的需要
好虫说的inmemory db说到底就是个fake
一般来说micro service oriented系统
fake都是很好做的
1/10集成测试的开销
能在单元测试阶段带来远超其成本的时间收益
何乐而不为
只能说你们的程序员不够懒
喜欢用复杂的方法找问题。。。
【在 p*****2 的大作中提到】
: 我的意思是具体工作起来是灵活的 没有一定的章法可遵循
: 什么都不能走极端 都是根据实际需要分配资源 包括人力 时间 测试 等等
: 能够合理分配并不容易 比你用教科书要复杂多了 很多tradeoff要考虑
: 你去看看每家公司的测试理念都有区别
|
p*****2
发帖数: 21240 | 59 你错了 我们当然做unit test
但是和其他相比 这个不是重点
【在 j********x 的大作中提到】
: 大多数时候你所谓的需要其实大部分也是自己拍脑袋想的
: best practice说白了就是让你不需要经过细致分析就能做到eliminate大多数可能出现
: 的需要
: 好虫说的inmemory db说到底就是个fake
: 一般来说micro service oriented系统
: fake都是很好做的
: 1/10集成测试的开销
: 能在单元测试阶段带来远超其成本的时间收益
: 何乐而不为
: 只能说你们的程序员不够懒
|
f*****w
发帖数: 2602 | 60 比如我有两个测试文件 test1.js 和 test2.js.
但是我只建了一个test database instance.
然后test1 和 test2 都做如下操作： 清空数据库，插入一些初始值，然后运行程序。
如果mocha很不幸地并行执行test1和test2 ， 那不就race condition了么 同时在操
作同一个数据库，一团糟了。
【在 p*****2 的大作中提到】
: 你错了 我们当然做unit test
: 但是和其他相比 这个不是重点
|
|
|
p*****2
发帖数: 21240 | 61 test1 和 test2 可以用两个db吧 如果本来就可以并行的话
【在 f*****w 的大作中提到】
: 比如我有两个测试文件 test1.js 和 test2.js.
: 但是我只建了一个test database instance.
: 然后test1 和 test2 都做如下操作： 清空数据库，插入一些初始值，然后运行程序。
: 如果mocha很不幸地并行执行test1和test2 ， 那不就race condition了么 同时在操
: 作同一个数据库，一团糟了。
|
f*****w
发帖数: 2602 | 62 这好像不是很好的解决方法啊 难道每次要加测试都去新建一个数据库instance 很快
就不堪罗嗦的步骤了
【在 p*****2 的大作中提到】
: test1 和 test2 可以用两个db吧 如果本来就可以并行的话
|
p*****2
发帖数: 21240 | 63 一个数据库instance应该可以create多个database吧？
【在 f*****w 的大作中提到】
: 这好像不是很好的解决方法啊 难道每次要加测试都去新建一个数据库instance 很快
: 就不堪罗嗦的步骤了
|
f*****w
发帖数: 2602 | 64 晕 难道大家在nodejs里面测试都是这麽个搞法
【在 p*****2 的大作中提到】
: 一个数据库instance应该可以create多个database吧？
|
j********x
发帖数: 2330 | 65 大多数时候你所谓的需要其实大部分也是自己拍脑袋想的
best practice说白了就是让你不需要经过细致分析就能做到eliminate大多数可能出现
的需要
好虫说的inmemory db说到底就是个fake
一般来说micro service oriented系统
fake都是很好做的
1/10集成测试的开销
能在单元测试阶段带来远超其成本的时间收益
何乐而不为
只能说你们的程序员不够懒
喜欢用复杂的方法找问题。。。
【在 p*****2 的大作中提到】
: 一个数据库instance应该可以create多个database吧？
|
p*****2
发帖数: 21240 | 66
我们没有这个问题。貌似jasmine是串行的？
【在 f*****w 的大作中提到】
: 晕 难道大家在nodejs里面测试都是这麽个搞法
|
p*****2
发帖数: 21240 | 67
我记得已经回过你这个了呀。
【在 j********x 的大作中提到】
: 大多数时候你所谓的需要其实大部分也是自己拍脑袋想的
: best practice说白了就是让你不需要经过细致分析就能做到eliminate大多数可能出现
: 的需要
: 好虫说的inmemory db说到底就是个fake
: 一般来说micro service oriented系统
: fake都是很好做的
: 1/10集成测试的开销
: 能在单元测试阶段带来远超其成本的时间收益
: 何乐而不为
: 只能说你们的程序员不够懒
|
j********x
发帖数: 2330 | 68 其实我发觉水平不高的装逼犯一个通病就是
不管说话发帖第一句总是要劈头盖脸说别人错了
然后毫无论据
请勿对号入座
【在 p*****2 的大作中提到】
: 你错了 我们当然做unit test
: 但是和其他相比 这个不是重点
|
j********x
发帖数: 2330 | 69 发帖重复还需要特别点名么。。。
【在 p*****2 的大作中提到】
:
: 我记得已经回过你这个了呀。
|
p*****2
发帖数: 21240 | 70
你不是也说别人拍脑袋吗？
【在 j********x 的大作中提到】
: 其实我发觉水平不高的装逼犯一个通病就是
: 不管说话发帖第一句总是要劈头盖脸说别人错了
: 然后毫无论据
: 请勿对号入座
|
|
|
j********x
发帖数: 2330 | 71 我说的是“很多时候你觉得的需要也是拍脑袋想出来的”
这个“你错了”
完全是两个层面上的论述
当然
你想怎么理解也是你的层面上的东西
【在 p*****2 的大作中提到】
:
: 你不是也说别人拍脑袋吗？
|
p*****2
发帖数: 21240 | 72
那你就mock呗
【在 f*****w 的大作中提到】
: 晕 难道大家在nodejs里面测试都是这麽个搞法
|
