什么TDD，让它见鬼去吧！，从入门到精通的Android进阶学习笔记整理

..... xxxx xxxx xxxx ......

返回值也是一个XML字符串， 表示成功或者失败（以及对应的失败消息）。

xxxx xxxx

这年头还用XML做参数，只能说这是一个老应用了!

####3

按照TDD的节奏， 张大胖写下第一个测试用例，并且让它失败。

public void OrderServiceTest{
public void testBonusPoints(){
String requestBody= …;
//执行submit方法
String result = orderService.submit( requestBody);
?? 验证积分， 可是怎么验证??
}
}

等一下，这个测试的输入参数容易构建，但是submit方法的返回值中根本就不会包含积分信息！那怎么才能我计算出的积分是正确的？

难道让submit方法返回积分数据？那就修改了本来是通用的接口协议，太不像话了！

第二个问题也很快浮现，积分计算的逻辑很简单，但是需要订单总金额和优惠券这两个信息，可是在测试用例中，这两个信息从哪里来？

订单总金额需要购物车，这是在数据库存放的，优惠券ID在submit方法的参数中，详情也在数据库中。

积分的计算这么简单，难道我还得先在数据库中创建一个购物车和优惠券，然后通过ShopCartService和CouponService从数据库读出来？这也太变态了吧?

不，单元测试一定要避开数据库，必须得用Mock的方式吧，张大胖知道一个Mock框架叫Mockito，挺好用的，就用它了。

张大胖又浏览了一下OrderService.submit这个长达2000多行的函数，这一看不打紧，张大胖发现这个函数依赖了另外七八个Service:  UserService， ShopCartService, CouponService …

这几个Service有的严重依赖数据库， 有的严重依赖Http ，有的依赖消息队列。

也就是说要想让submit方法顺利执行，必须得把这七八个Service都Mock出来，让它们能协调工作，例如：

给一个userID，就能返回一个正确的user对象。

给一个couponID，就能返回一个正确的coupon对象。

Mockito能实现这个功能，但是协调七八个个Service的相关对象，需要写出大量代码才行！测试用例中的代码会变得非常复杂、非常脆弱。

张大胖傻眼了 ！自己连一个测试用例都写不出来，还搞什么TDD?

####4

张大胖叹了一口气， 放弃了写测试用例的想法， 在OrderService.submit方法中，找到了合适的地方，然后根据订单金额和优惠券信息，写了几十行代码，把积分计算了出来，保存到数据库中。

然后启动程序，通过界面的方式提交了几个订单，涵盖了各种情况， 做了手工测试，然后检查数据库，他高兴地发现，积分计算完全正确，这才花了不到一个小时。

什么TDD， 让它见鬼去吧！

文章不易，如果大家喜欢这篇文章，或者对你有帮助希望大家多多，点赞，转发，关注 哦。文章会持续更新的。绝对干货！！！

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）

最后

我见过很多技术leader在面试的时候，遇到处于迷茫期的大龄程序员，比面试官年龄都大。这些人有一些共同特征：可能工作了7、8年，还是每天重复给业务部门写代码，工作内容的重复性比较高，没有什么技术含量的工作。问到这些人的职业规划时，他们也没有太多想法。

其实30岁到40岁是一个人职业发展的黄金阶段，一定要在业务范围内的扩张，技术广度和深度提升上有自己的计划，才有助于在职业发展上有持续的发展路径，而不至于停滞不前。

不断奔跑，你就知道学习的意义所在！

以上进阶BATJ大厂学习资料可以免费分享给大家，需要完整版的朋友，【点这里可以看到全部内容】。

所在！

以上进阶BATJ大厂学习资料可以免费分享给大家，需要完整版的朋友，【点这里可以看到全部内容】。