最近前后端联调不掉坑了，但是又栽在了测试小姐姐的手里。
场景1：
产品：虽然列表的字段是社区，但因社区存在重复，所以需要在社区名称前面把街道也带上，即该字段回显成“xx街道/xx社区”，好让用户明确定位社区。
后端：分streetName、communityName两个字段返回。
我：前端实现逻辑是，只有接口同时把街道名称和社区名称返回了，才显示“xx街道/xx社区”，否则都显示--
这时，测试小姐姐站出来说：
前端应该尊重接口返回的实际情况，如果接口只返回了街道名称就只显示街道名称，如果只返回了社区名称，那么就只显示社区名称，不要人为的隐瞒接口情况。
我：如果接口只返回了社区名称，那只显示社区名称没问题，但是如果接口只返回了街道名称，那么只显示街道就会显性的将问题暴露到用户面前，因为列表字段名毕竟叫社区。
#### 所以，该不该因尊重接口事实，而将问题显性的暴露给用户，影响用户使用体验？
场景2：
产品：简历中，如果用户已经实名了，则根据用户身份证号回显出生日期，并不允许修改。
我：前端实现逻辑是，只要用户实名了，不管用户之前有没有填写过出生日期，在用户编辑简历时，出生日期字段都按身份证号里截取的显示，而不是显示简历详情接口返回的出生日期。
注：之所以这样实现是基于以下因素的考量，因为用户实名了是不允许修改出生日期的，所以如果用户发现之前填写的出生日期是错的，他也是没办法修改的。
这时，测试小姐姐又站出来了：
如果用户实名了，应该由后端去刷用户的出生日期，而不是由前端人为的显示正确的出生日期，如果后端未刷，那在编辑简历时，前端也只能显示接口返回的错误的出生日期。
我：之前不知道用户实名后，后端会去刷新用户的出生日期，那既然后端处理了，那前端是要尊重接口返回。
讨论
在以上两个场景中，测试所强调的回显需基于接口事实的原则，是需要严格的遵守，即使把问题暴露给用户，还是可以根据用户体验，选择性的优化？
