SHUHARI 的博客

这两天用闲暇时间写了一个小工具：Tidy Explorer，其实就是控制资源管理器上边那一排快捷方式的显示或隐藏。这些东西对我来说是根本用不着的，特别是那个 3D 对象，而 Win10 却固执地把它们设置成默认视图，相当讨厌。

我们都知道，测试是有层次的。一般来说，测试的组织应该形成类似下图那样金字塔型的结构：在底层有数量很大、短小而快速的单元测试，在开发过程中提供实时反馈；中间层是集成测试，验证各个组件组合在一起是否正常工作；再往上则有所分化，依照不同的侧重点与表现形式、有系统测试、UI 测试、用户验收测试（UAT）、接口测试、端到端测试等多种不同的称呼。从自底向上的角度看，它们应该在数量上逐层递减，但测试覆盖的范围则更大（相应的执行速度也会变慢），在损失代码局部细节的同时，也获得了更广泛的全局视角。

前言：本文是 James O Coplien 的文章《为什么大多数单元测试是浪费》第一部分的中文翻译，原文地址: Why Most Unit Testing is Waste。关于该翻译的介绍与背景，请参考 索引 部分。对于其中部分可能不太容易理解的地方，我尝试自己加入一些说明，您可以参考最后部分的脚注。

前言：本文是 James O Coplien 的文章《为什么大多数单元测试是浪费》第二部分的中文翻译。原文地址：Segue。关于该翻译的介绍与背景，请参考 索引 部分。对于其中部分可能不太容易理解的地方，我尝试自己加入一些说明，您可以参考最后部分的脚注。

TDD （测试驱动开发）是敏捷开发、特别是极限编程（XP）的核心实践之一，也是我长期以来一直坚持采用的方法。因此，当我最近偶然从一个链接发现这篇文章时，它带给我的震动是可想而知的。虽然在之前我也模糊地感觉到单元测试可能存在的一些问题，但一直相信是自己水平不够、认识有限的原因，没有更深入地思考过。也曾听说过 DHH（Ruby on Rails 框架的作者）对 TDD 的反对意见，但也只是想那可能是 RoR 框架本身的局限，不一定是广泛适用的结论。

最近，Go 语言社区一件让人比较挫败的事情是，为了简化错误处理而提出的 try 提案，几经变更，又经过社区的反复讨论，最后还是黄了。关于该问题的一些讨论线索可以在 Github 专题讨论页面 Proposal: A built-in Go error check function, "try" #32437 上看到。

一个语法提案没有通过本来在开源社区不算什么大事，本来通过民主讨论决定语言的发展方向，也是集思广益的正常之举。但我以为在这个问题之后，折射出 Go 语言本身、以及社区目前存在的一些问题，这还是值得玩味的。

在网上看到一种说法：Windows 在服务器市场的占有率远高于 Linux。这个说法让人惊讶，因为它和我一直以来的主观印象、以及看到过的一些市场调查结果是直接矛盾的。所以我决定研究一下这到底是怎么回事。

在以前的文章 有趣的项目 - 在浏览器中运行 Visual Studio Code， 我介绍过 Coder 开发团队将 Visual Studio Code 搬到浏览器里的尝试。这是一个有趣的项目，不过没有想到的是，这之后不久微软官方就推出了 VSCode 的远程开发扩展，这简直是官方逼死同人的节奏。从 Coder 官网 的信息来看，他们似乎已将精力主要放到企业版本，这应该算一个生不逢时的产品吧。今天我们来介绍一下微软自己基于 VSCode 的远程开发平台。

很抱歉通知本站的各位访客，从下个月起，本站域名将由原来的 yuhao.space 迁移到 shuhari.dev，除相关名称和链接有所调整，整体内容不变。如果您收藏了本站内容，请及时更新链接。例如，如果您从前访问的地址如下：

• https://yuhao.space/blog/2018/01/more-free-ebooks

那么只要修改域名，其余部分不变，就可以继续访问：

• https://shuhari.dev/blog/2018/01/more-free-ebooks

众所周知，Visual Studio Code 是基于 Electron 的，而Electron 又是一个“双头怪”——基于 Web 技术的桌面应用平台。但在最近，Coder 的开发者最近做了有趣的尝试，让我们可以把整个 VSCode 放到浏览器中去运行，并且我们也可以很容易地去亲身体验他们的工作成果。如果你有兴趣的话，不妨跟我一起尝试一下。