一周一周过的真快，感觉没做什么，一周时间就这么流荡过去了。本周主要任务有两项，其中一项就是单元测试。
写过单元测试的朋友们请举手，哈哈，虽然看不到，估计不是很多。写过有效单元测试的请举手，估计又少了一些。
那么今天就从单元测试说起，最后聊聊最近的一些想法
初识单元测试
不知大家工作经验如何，对于我来说，工作很多年，单元测试未曾好好写过，如果你现在所在公司在做单元测试，恭喜你，在我看来你多半在一家靠谱的公司。
继续上一篇的话题，项目迁移工作已基本初见效果，现在要开始整理单元测试了，众所周知在系统证实上线前，测试工作不能少。
同时还要考虑到今后DevOps的应用场景，所以单元测试的代码覆盖率要提上去，并且今后是要通过Sonar等系统生成相应的测试报告的。
那么什么是单元测试呢，顾名思义只测这一小块，一个小的Unit。那其关键点在于Mock，从而做到功能实现类之间的解藕。对，解藕～～
怎么做
以前，我在使用JUnit包时，仅仅是围绕@Test进行的function的编写，并实际触发相应类的全部功能，从而实现具体功能的测试。编写困难，测试消耗时间也长。
你需要考虑初始化是每个对象所需要的依赖以及相应的参数才能创建数真实的调用类。
应该怎么做呢，此次项目整理过程中，我尝试了两个单元测试框架Mockito和JMockit。前者得到spring的官方推荐，后者则是开源社区热捧。两者语法迥异，针对我的目前用到功能来说，功能基本一致。
两个框架的核心就是通过合理Mock进行有效的单元内部测试，尽可能将依赖层分离。
听起来不是很难对吧，但实际要复杂的多，由于程序自身架构设计的原因，每一层都有一些更为深入的dependency的调用需要进行Mock，同时你还清楚的知道那些逻辑是需要真实用运行，不能进行简单Mock的。
这个过程我正在结合当前项目进行实验，也许今后可以总结出一些有用的东西分享。
结对编程和TDD
这两个说法估计做点技术人的并不陌生，但还是那个问题，有谁真的做过呢，又是具体怎么做的呢，效果如何，能回答这些问题的人估计也是寥寥无几。
近期的公司培训让我对此有了初步的认识，有效的单元测试不仅仅是简单的代码覆盖率，还有合理的测试用例的设计。总结以下几点：
- 不会写单元测试的程序员，不是好程序员
- 单元测试代码覆盖率应该做到100%
- 测试用例设计应该从业务需求角度设计，不应该从实现功能代码角度设计，测试用例满足，即功能实现（TDD）
- 结对编程，可以一人写测试用例，一人写功能实现，两者交叉验证
- 完整的单元测试开发量与功能实现开发量比例应该在 2:1 至 3:1
在我看来，我一直认为有必要写单元测试。但最近让我更加深入的认识到，其作用和目的，以及其编写时考虑的问题。
性能测试（PT）
测试有很多种，单元测试是开发人员要做的工作，那么上线前的测试环节还有SIT UAT PT等，今天在公司初步学习了Performance Test（PT）性能测试。
我们经常提到的压力测试，就被包含在其中。PT会包含：
- Peak Test
- Stress Test
- Soak Test
一般通过这三个阶段的测试，收集系统运行数据，并形成报告，看测试是否通过或者查找问题。
PT具体内容也不少，此迁移项目最后也是要上PT来验证迁移效果，所以后续也会有所总结再分享，这里就不多说了。
近期工作的感受
最近工作，看似简单，没有什么高科技含量的工作，但也能从总学到不少东西，正好也弥补我之前工作中的不足，让我更为深入的思考和体会一些技术细节，不失为一件好事情。
还是喜欢技术，对于技术我从未放弃，自己也在不断的提升，希望不要落下什么，最近也在系统的学习一些成熟技术框架。
题外话
近期看了巴菲特的伯克希尔哈撒韦公司股东年会直播。第一次看，了解到很多，主要是见识一下场面😛
巴菲特和芒格两人的处事风格让我深深感觉到他们多年的自律和积淀，两位老者很放松，很睿智，这样的高龄还可以如此洒脱，真是难得啊，让人无比羡慕。
股东的提问也很发散，展示出其公司治理中，股东大会的一个特色，让人感觉其管理体制的完善和包容
至于经济问题，我就听听热闹，我也没有持有他们的公司的股票，也没有啥钱去炒股，随波逐流而已。
至于近期工作，英语口语沟通可能还是最大问题，不是不能沟通，只是沟通效果不好。关键问题在于印度口音的英语我实在是……希望今后不要把我带跑了
你有这样的感觉吗，人越活会越孤独，是心灵孤独的那种，因为可以感同身受理解你的人会越来越少。我有时会思考这个问题，感觉会呢。
我的时间规划要在合理一些，感觉太多事情想做，时间太有限了。效率也要提升才可以。