它山之玉可以重构:身份证号码解析、验证工具(第二天)

原创
2012/12/07 05:21
阅读数 501

又是一个清新的早晨, 开始我们新的测试之旅.

2 - 第二个测试, 从身份号取到正确的性别信息.

==>很简单,依葫芦画瓢, 容易的写出第二个测试.


(本文版权属于© 2012 - 2013 予沁安

==>很惊奇,居然没有过? 却不知, 测试的旅途中,Failed是常态.



==>好吧, 看看错误在哪?


在取性别代码时,作了验证,而且是全套. 为什么取地址时却不验证呢? 这个不一致性来源于---不是测试驱动,赫赫.

==>解决方案,把验证去掉, 呵呵. 一是解耦, 二是敏捷,还没有测试到的东西,不花过多的时间.


==>搞定.



==>可是,回过头来看测试的两个断言,一个生日,一个性别,毫无相关嘛? 于是,就有了下面的测试拆分:


==>测试类的名称也作了相应的修改,表意性更强. 然后,增加一个女性的测试,只是完善测试路径覆盖而已。



==》最后,很有成就感的看看测试结果

最后,成品代码和测试:
SocialID.cs SocialIDSpecs.cs

(本文版权属于© 2012 - 2013 予沁安 | 转载请注明作者和出处

展开阅读全文
打赏
0
9 收藏
分享
加载中
予沁安博主

引用来自“liuex”的评论

关于getGenderCode中的验证,更多的是个人风格的原因:
1、任何时候只要发现有错误,就应按立即终止执行。因为我觉得只要出现了错误,那么后续的任何指令都是没有意义的(尝试修复错误的指令除外,这种指令可以有)。getGenderCode这里的情况,如果身份证号码本身就是错误的,那么再去判断这个身份的性别完全就是没有意义的事情了。
2、我对程序的“健壮性”有些疑惑:A、你期望一个函数绝对健壮,能够自动修复处理大多数不正常的、意外的、错误的输入,还是B、你期望一个函数只接受规定的输入,其他即使是语义正确、但是不符合规定的输入都会遭到拒绝,程序终止。我个人选择B,因为这种情况是“确定的”,“没有风险的”。只要是符合规定的输入,那么输出一定就是确定的,可预测的。反之看看A方式:如果这种代码积累的比较多的话,上了生产一定会不时给你爆个“意外惊喜”出来……总结就是,我认为保持简单优先于程序健壮。B方式下,如果一个语义正确的输入被程序拒绝了,很容易就能定位到错误在哪,以及如何修正。关于健壮性的一个典型例子就是HTML解析器,HTML解析器为了能够兼容处理各种乱七八糟错误的HTML,解析程序变得异常的复杂。而XML解析器就不考虑健壮的问题,只要XML中有错误则立即终止,保持了简单和简洁。

同意,我的实现在构造器中。
2012/12/11 07:08
回复
举报
关于getGenderCode中的验证,更多的是个人风格的原因:
1、任何时候只要发现有错误,就应按立即终止执行。因为我觉得只要出现了错误,那么后续的任何指令都是没有意义的(尝试修复错误的指令除外,这种指令可以有)。getGenderCode这里的情况,如果身份证号码本身就是错误的,那么再去判断这个身份的性别完全就是没有意义的事情了。
2、我对程序的“健壮性”有些疑惑:A、你期望一个函数绝对健壮,能够自动修复处理大多数不正常的、意外的、错误的输入,还是B、你期望一个函数只接受规定的输入,其他即使是语义正确、但是不符合规定的输入都会遭到拒绝,程序终止。我个人选择B,因为这种情况是“确定的”,“没有风险的”。只要是符合规定的输入,那么输出一定就是确定的,可预测的。反之看看A方式:如果这种代码积累的比较多的话,上了生产一定会不时给你爆个“意外惊喜”出来……总结就是,我认为保持简单优先于程序健壮。B方式下,如果一个语义正确的输入被程序拒绝了,很容易就能定位到错误在哪,以及如何修正。关于健壮性的一个典型例子就是HTML解析器,HTML解析器为了能够兼容处理各种乱七八糟错误的HTML,解析程序变得异常的复杂。而XML解析器就不考虑健壮的问题,只要XML中有错误则立即终止,保持了简单和简洁。
2012/12/08 21:34
回复
举报
更多评论
打赏
2 评论
9 收藏
0
分享
返回顶部
顶部