软件工程师为什么要懂测试

       做为软件开发工程师一定要懂测试. 你不懂你的全局观还不够. 架构师需要理解测试. 你不懂测试你不会理解测试过程痛, 不能友好的与测试工程师协作. 你不测试说明你的LEVEL还不够高, 对于软件质量理解还不够.  远的测试过程不说, 先说说单元测试UT. 很多开发工程师, 什么高大上微服务项目都做过了, 还是写不好单元测试. 单元测试这是一个普通的技能了. 你写不好, 说明你不专业. 阅读以下内容让我们专业点儿:

      一. 测试的价值

        Tests help us catch mistakes. Tests help us shape our design to actual use.

       注意词Shape,  再者是

Tests help us avoid gold-plating by being explicit about what the required behavior is.

         很多测试因素直接或间接影响 产出效率, 如下图

    测试也是个设计工具, 迭代的思想:

 

    TDD思想出来了, 循环迭代, 有时候与我们做成一件事过程也是相同的.

      二. 测试不要依赖真实数据库
        使用内存数据库, 如下的实践

• Substitute test doubles for third-party library dependencies, wrapping them with your own adapters where necessary. The tricky stuff is then encapsulated inside those adapters that you can test separately from the rest of application logic. 
• Keep test code and the resources they use together, perhaps in the same package. 
• Let test code produce the resources it needs rather than keeping them separate from the source code. 
• Have your tests set up the context they need. Don’t rely on any other tests being run before the one you’re writing. 
• Use an in-memory database for integration tests that require persistence, as it greatly simplifies the problem of starting tests with a clean data set. Plus, they’re generally superfast to boot up. 
• Split threaded code into asynchronous and synchronous halves, with all application logic in a regular, synchronous unit of code that you can easily test without complications, leaving the tricky concurrency stuff to a small, dedicated group of tests.

     我们在Test double 概念中也看到 Fake 对象提及 内存数据库

• Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
• Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example).
• Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.
• Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
• Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don't expect and are checked during verification to ensure they got all the calls they were expecting.

     还有一句有意思话

Friends Don't Let Friends Hit The Database In Tests

     其它BLOG, 还有

Lightweight, drop-in replacement for the database

Aside from substituting a test double for your data access object, the next best thing might be to use a lightweight replacement for your database. For instance, if your persistence layer is built on an ORM framework and you don’t need to hand-craft SQL statements, it likely doesn’t make much of a difference whether the underlying database product is an Oracle, MySQL, or PostgreSQL. In fact, most likely you should be able to swap in something much more lightweight an in-memory, in-process database such as HyperSQL (also known as HSQLDB). The key advantage of an in-memory, in-process database is that such a lightweight alter native conveniently avoids the slowest links in the persistence chain the network calls and the file access.

    

   So far you’ve  learned that unit tests should stay away from the network  interface  and the filesystem if execution speed is a factor. File I/O isn’t exclusive to database.

      Separate Dependencies Where Possible.  尽可能隔离依赖               

                                                                 -- from <<Test-Driving JavaScript Applications >>
      等以上这些都表达不要依赖数据库等外部资源.  笔者在某中型公司框架中还看到误人子弟的单元测试示例,连接了数据库, 那已经不是单元测试, 已变为集成测试.

  三.  Arrange-act-assert 结构

     良好的结构是好的开端

        四. 一些原则

         我们原则有 “测试驱动模块化设计”

      “SOLID原则”

       代码可测试性原则:

避免复杂private方法
避免final方法
避免static方法
使用new时小心
避免逻辑在构造函数中
避免Singleton
优先组合而不继承
包装外部组件

总结

      理解测试, 是我们需要敏捷软件开发过程基础. 做为一个软件开发工程师你需要比任何一个人都关注质量. 你不能总想着有人帮你测试. 相反是你对你的程序复杂找出BUG修正在正在交给其他人前. 原因很简单, 开发软件总有BUG, 修复BUG是昂贵的. 上升高度, 你的产出影响了其他人, 如何提高你的影响力.

---

今天先到这儿，希望对您技术领导力， 企业管理，物联网,  系统架构设计与评估，团队管理, 项目管理, 产品管理,团队建设 有参考作用 , 您可能感兴趣的文章:
2017-2018年Scrum状态调查报告
2016年测试状态调查
2017年IT行业测试调查报告
项目管理－习惯发生范围变更
前端性能核对表Checklist-2018
大型电商互联网性能优化案例
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。