分享最近遇到的鬼故事
当初开发完A功能后有顺手写了UT确保该功能基本能动
后来有同事在开发B功能时把他的B功能加进去我的UT default flow内
也没有请我code review
导致我在跑UT时发现不预期的行为
搞了一阵子才发现是他乱用了我的UT
虽然说AB这两个功能初始化的部分完全相同
写两个UT确实是会有很多重复的地方
但一个功能一个UT应该是正确的观念吧!?
不知大家有什么想法，或类似案例分享或怎么改善XD

你是对的

把同事扁一顿

鬼故事在于 他不用找人code review 就可以改东西吧

UT = “unit” test，请他去查查什么叫unit

这就是为何在台湾9成公司里 根本不要UI的原因 不但没有享受到UT的好处 一堆脑残还会给团队添乱 算惹吧UT不是写了就放著没事耶 UT也是要跟着程式一起维护的

有一份工作有写过,因为写UT才发现自己CODE高耦合才决定去学设计模式,不过后来工作公司都没写单元测试的

还好我同事写完测试都会先注解掉assert 才发pr真不愧是老鸟

扁你同事+1，在台湾我们先解决人。

推上版控自动test 跑不过不能merge回主要分支

还有公司没有版控喔

问题是没有要求code review

无情开扁

这哪有什么，就同事写了个bug的意思啊

你是对的

等于同事写了个bug没人发现就上线，该怎么处理就怎么处理没有人能提出线上版本永远不会出问题的工作方法吧？UT又不是银弹

不是bug 只是UT跑完的结果不是我原本预期的发现是我原文没说的很清楚XD

比他资深就请他修或跟他pair 修。比他资浅就自己修吧

写UT让我很放心改A不会错到B，也在写UT时没有分的很好的程式再次有机会被重构，降低耦合

会改到一起不是说明做的范围很接近？平常应该会交流吧

原来现在unit test 已经开始简称成UT了 那整合测试呢 IT?

UT只出现在JD过

Uniqlo

我建议写一个UT的UT，以确保你的UT没有被改坏

要的功能是 自测

写两个UT 如果预期之后有更多UT初始化过程一样的话就抽出来reuse

没review怎么进code是说 我最近在跟组内学长谈UT case要解耦by class测试学长一直跟我扯整个团队一起测试就是UT好想离职 草包掌权没有UI或是没有上层带起来就不能跑 是在UT懒觉吗