我在这里问的是你发现单元测试是在你自己的实践中.
了解引进单元测试的优缺点,障碍,单元测试过程中的缺陷,单元测试获得的价值等等,这些开发者在日常实践中已经观察到了这一点.
我们在做什么
我在具有Oracle后端的Web应用程序上工作.
该应用已经投入使用了8年,维护工作也在不断加强.
我的开发团队执行单元测试脚本(UTS),旨在通过给定代码包的单元测试来开发人员.
这些UTS是2-20页Word文档,用于描述程序包的目的,结构以及封装内给定模块的详细说明.
UTS总结了描述包的应用程序测试的部分.
这听起来不像我的单元测试.这听起来更像是系统集成测试,包含一个包的描述.
它当然不是自动化的.
随着我们的UTS实践在当前的状态,管理/编辑/其他文件不是一件微不足道的任务.当需要对特定包装进行增强或维护工作时,没有严格的检测程序来保证产品满意.
相反,我们有这个更高级别的UTS遵循,这并不接近于保证各种代码跟踪中的正确输出.
我一直处于几年以前必须编写单元测试的情况,我完全看到清洁高效的开发周期的优势,但这些都是我面临的一些问题.
>开发可能很干净,但是当需求变化时,您通常必须在单元测试级别重新启动.这当然是一个流程问题而不是TDD问题.
>测试GUI的东西是不可能的OOTB与大多数工具
>确保您使用最佳实践需要大量的自律.这是不幸的,但从测试驱动到“测试支持”开发很容易.我的意思是以最好的意图开始,但不坚持首先编写测试的想法.
总而言之,我赞成使用单元测试来提高代码的稳定性,可靠性,简洁性和一般质量.回归测试是单元测试成为自己的巨大领域,我确信希望别人可以比我更好地解释他们的观点.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。