
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
测试驱动开发是目前大多数软件开发程序员在开发软件的时候会经常用到的一种开发方式,而本文我们就通过案例分析来了解一下,测试驱动开发都有哪些常用方法。
我们一般在项目开发中进行的功能测试,是可以保证当期中业务流程。但是即便功能测试的过程包含了所有的过往功能,也只能保证业务流程是正确的,不能保证你的设计在未来的扩展中是正确的(举例就是业务可能只需要正常流程,但是没有异常流程的需求)。
所以,如果要代码能实现所有计划的功能,就要由开发者来编写其对应的测试模块。因为是开发人员,所以知道自己的所有逻辑组合是什么,而根据这种需求编写的测试代码则可以长久地对你的系统进行测试。而这就是就是:
TDD(测试驱动开发)
测试驱动开发中主要的准则是:
在编写业务代码之前先编写单元测试。
这条准则的目的在于:不要编写没有单元测试的代码。实际上我们在编写功能业务的时候,一般都会假设一个入口,然后再经过一段逻辑处理之后,终返回一个结果。而先编写单元测试的目的,就是先将你的这个假设直接落地到代码中,那么在后续的编程过程中你就可以忽略这部分的假设,专注于逻辑编写,甚至即使你后忘记了之前的假设也不要紧,因为你已经将他写道代码中了。
而这一准则的进一步拆解,可以将其细化为三个准则:
在编写不能通过的单元测试前,不可以编写生产代码。
只可编写刚好不能通过的单元测试,不能编译也算。
只可编写刚好足以通过当前失败测试的生产代码。
根据细分的这三个准则,我们可以将我们编写一个逻辑的的步骤变成:写一个刚好失败的单元测试,然后用刚好满足逻辑的生产代码满足它。这样一个小循环可能只是在一两分钟内就进行一次。而在IDEA等现代IDE的帮助下,可以在test包下的同包路径创建对应的测试方法,大大加快了单元测试的编写时间。而通过刚好的异常,让每一次的业务逻辑得到了控制,通过刚好满足则让每一次生产代码的编写不会过度发散。因为如果你对生产代码过度设计,那么你也需要对应的单元测试代码来保证你设计的的得当性。
如果按这种循环进行编写,则我们在编写业务代码的同时只需要多十几秒就可以完成单元测试的编写。而单元测试可以完整地覆盖业务单元元。但是随着业务代码的增加,测试代码的数量也将急剧增加,其对应的管理也是一种挑战。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。