聊聊集成
从业务域角度看集成，首先要定义什么是单元，传递一个命令就是单元，。
那么，在这个领域里，我们的测试应该有多少个呢？
首先，要看我们有多少个变化因子，marsrover面向的四个不同方向状态在接受三个命令时的处理是不一样的。所以四乘三共有12个case。这些都是单元测试。测试的是单个命令的场景。
接着需要考虑场景之间的联动，也是一种集成测试。那你可能需要发带有几个命令的字符串，看看结果是不是对的。
happy path完了，再考虑一下异常分支，没发送命令是一个case，发送了不支持的命令也是一个case。后者好像没说要怎么处理呢，记得澄清。本文就不深入聊这些细节了。
另外，由于本题没有提出最大长度问题，这个我们可以先不测，但是这个是个技术原因必须限制的数字，毕竟单批量发送还是不限制不行的。根据我们上一篇，在实际工作中一定要探讨这个问题，并明确在规格上发布给使用者，不要脑补，如过业务方确实无所谓，就由我们提出一个数字，双方都认可了，放在一个地方。
而在方案域，集成则有不同的含义。不同的设计也会需要不同的集成测试。
先说分层，我会把与外面交互的部分划为一层，也就是把“0 0 N”和“MLRR”之类解析成领域概念的为一层。
解析完之后处理核心业务逻辑的部分再分一层，靠main或XXController之类的调度。
那么这两层的集成呢就是方案域的集成测试了。不过这个时候，你会发现，解析的部分单独测，解析出来的结果执行的部分单独测，最后他们集成起来的部分只需要mock测试测一个用例就好了。
不但测试简单了，扩展其实也会简单，这样我们将来如果命令发生变化比如，开始这么写命令 “M2 L R”也就是移动的时候加入了数字控制移动多少格，为了好解析，我们加入了空格来分隔。这种变化对于执行的来说，并无感知，因为这个变化悲伤层负责解析的部分已经隔离掉了。
聊聊设计
这个题一开始，很多人肯定是一大串if来解决3个command的if和四个方向的if。
写完之后呢，就会开始重构，重构成什么样子的就都有了，比如下面这个：
这个重构完，通常if就没有了。
但是有很明显的循环依赖，所有人都能改MarsRover，这封装性也太差了。那我们提取一个数据传输对象来提升一下封装性吧，像下面这样：
这么做循环依赖貌似少了，封装性也提高了，但Direction和RoverStatus还是有个循环依赖，进一步消除一下试试：
终于，所有的循环依赖都干掉了，但这图看着好复杂啊而且有个问题，那就是Command和DIrection严重耦合，Direction的三个方法明显是Command的延伸，每加一个Command，Direction脱不了也要加个方法。这个设计肯定是不好的。我们可以发现DirectionValue实际上是可以不知道Move的相关概念的，方向之间自然的有左右关系，所以可以改造成这样的设计：
每个DirectionValue都有一个index，左转可以通过+3然后%4的方式完成，右转可以通过+1然后%4的方式完成，不需要外面的其他概念，实现也很简单。
这下貌似清静了，但实际上Move这个Command里面有四个if还是不好消掉，如果因此搞四个新的子类，会有点啰嗦。这个时候如果采用函数式的方式，把DirectionValue的四个值和对应的移动算法用一个Map封装起来，其实就比较简单了。
这个题做到这，可以加入一些新需求，比如：
新需求1，加一个新指令，如果接受到B指令，那么久会进入倒车状态，这个时候M跟正向的时候是反的。注意，指令的操作虽然反了，但是朝向不能变。比如朝北的M之后，y坐标是减了，但是朝向必须还是北。
新需求2，有一个雷达功能，执行完判断一下自己是不是掉沟里了，如果掉沟里了，就再map上打个记号X（只是表达这个意思，不一定非要是字符串X），后面的rover会忽略走向这个记号的命令（当火星车掉到沟里时，调用init方法创建一辆新的火星车，但旧的火星车还要在沟里，不能消失）。判断无法动的方式目前先用随机数吧，正好练练mock。
新需求3，地图有不同的地形，有的地形能触发无法移动，有的不能。掉沟里是火星车自己在地图上打的标记，不同地形是火星车在来到火星时就知道的地图信息（考虑，X标在哪？真实的地图上吗？真实的世界的映射的地图，和标记了X的地图应该是个什么关系？）
新需求4，车也有状态，有的状态，车会忽略一些指令，比如左转坏了，会忽略左转指令
新需求5，车还分类型，比如Bus，占两格，他的坐标是车头的坐标，但是它左拐时周边必须有可以拐的空间（右侧两格都不能是X），否则会忽略掉指令。
Bus可能会在拐弯时坏掉，
引入卡车，卡车占两格，不同于Bus的是，卡车如果车头处没有坏掉，可以接受特殊指令来脱钩车头，其他车接受这个指令无反应。