分布式鼻子 1.2.0

# distributed-nose 无烦恼地在多个节点上分发您的测试

## TLDR

### 之前

机器1

$ nosetests long_test_suite … 执行了1312个测试，耗时401.109秒

机器2

$ echo “我很无聊 :(” 我很无聊 :( $ uptime | awk -F’load average:’ ‘{ print “Load: “ $2 }’ 负载: 0.00, 0.00, 0.00

开发者

$ google-chrome http://news.ycombinator.com

### 之后

机器1

$ export NOSE_NODES=2; $ export NOSE_NODE_NUMBER=1; $ nosetests long_test_suite … 执行了660个测试，耗时220.502秒

机器2

$ echo “我感觉很爱” 我感觉很爱 $ export NOSE_NODES=2; $ export NOSE_NODE_NUMBER=2; $ nosetests long_test_suite … 执行了652个测试，耗时214.007秒

## 您的测试套件的故事

### 未测试代码的压迫

您的测试套件的故事有其英雄和反派，有胜利和失误。像许多其他故事一样，它从一个孤独的英雄开始。大学毕业后，她加入了一个快乐的一群软件工程冒险家。在管理层领导和广泛的角色支持下，他们创造了普通百姓喜爱和需要的物品。

慢慢地，慢慢地，一切开始改变。结构不良且耦合度高的代码悄无声息地进入代码库，使得修改变得越来越困难，也让狡猾的bug得以滋生。党员们开始频繁地破坏项目的各个部分，因为单凭一个人很难快速地全面审视这个庞大的领域。代码区域变得难以进入，就像巨龙和未知的事物阻挡了所有试图进入的人。

在这期间，我们的英雄怀着沉重的心情观察着这一切。对于这个未经测试的代码库，我们应该怎么办呢？显然，她不可能独自改变一切！她只是一个人而已！

最终，日常的斗争让她疲惫不堪。

“够了够了！”

她决定，开始思索如何最好地打击未测试代码的压迫。

“我要编写测试，并将它们提交到源代码控制！”

她说，理解到工作代码是最好的论据。

### 鼻子驱动的和平

有步骤地使用和教授[Nose](https://github.com/nose-devs/nose)，她在内部招募志同道合的开发者，组成了一个快乐的团队。他们是TDD的联盟，决心成功。测试代码在大量高质量代码的推动下被提交！

联盟的壮举在其他开发者中引起了激动。另一位英雄决定，如果运行一些测试是好的，那么一直运行所有测试就更好了！他挥舞着系统管理的帽子，利用额外的服务器资源，从而产生了持续集成过程。

然而，我们的英雄对自己的成功过于自信。他们几乎没有尝试去证明这种做法的合理性，关于编写测试花费的时间的消息传到了管理层。管理层监督开始压制这个刚刚兴起的联盟。

### 管理层的反击

“如果你有时间编写测试，那一定是我没有给你足够的任务！”

他们咆哮着，威胁着使用最危险的武器：被动的敌意。

再一次，我们的英雄鼓起勇气，通过巨大的努力，勇敢地用高质量的剑斩断了管理层的反对。一个新时代的和平与生产力开始了，项目蓬勃发展。

但这份和平并未持续太久。慢速测试运行的幽灵笼罩在我们的英雄头上。不久，测试失败被忽视。开发者不再等待测试完成！测试套件开始衰败。

### 多进程的到来

开发者抱怨，管理层也毫不客气地抛出“我早就告诉你了”的言论。没有测试的时代黑暗再次威胁要回来。

“我要加速我们的测试！”

一个声音喊了出来。又是我们的英雄，发誓要打击衰败的根本原因。

翻阅古代文献，她很快发现了[多进程](http://nose.readthedocs.org/en/latest/plugins/multiprocess.html)。

“这将使我们摆脱单核的束缚。”

她自信地宣布。几个小时后，她的8核机器迅速通过了测试。不久，多进程在CI服务器上使用，测试速度迅速提升。

测试领域一切正常！她的同事们为她举行了一个休息室派对。Python Meetup讨论如流水般涌现，TDD再次受到大家的喜爱。

就像之前的和平一样，这次也只是一时的。因为增加更多的核心代价高昂。快进几个测试周期后，曾经快速的测试套件经常使健壮的多核CI服务器不堪重负。

### 分布式绝望

回想起实施多进程的便利，我们的英雄知道下一步该做什么。她只需将测试分散到多个服务器上！她自信地查阅了那些古代文献，因为解决方案似乎显而易见。

但是等等！

简单的指南在哪里？

我们的英雄不是巫师。她无法解读那些古代卷轴上的分布式系统。她没有时间去接受正式的巫师训练，而且涉及到的变量太多，让人难以置信。

当曾经快速进行的测试逐渐变慢时，绝望情绪开始蔓延。对于我们这些探险者来说，前景一片黯淡，因为加快测试本身的评估揭示了巨大的挑战。甚至有人建议完全放弃测试套件，转而专注于速度！

派系形成，整个团队面临完全分裂的威胁！

### 分布式鼻：可扩展的解决方案

“等一下。”

一个清晰的声音打破了寂静。又是我们的英雄。

“为什么我们的测试运行器需要通信来协调？我们的Memcached服务器需要相同级别的协调，并且可以轻松实现！”

被一个想法的闪烁所触动，她开始工作。她坚定不移，仔细阅读了关于[一致性哈希](http://en.wikipedia.org/wiki/Consistent_hashing)的书籍。一旦她的脑海中明确了解决方案，她就遇到了一个给予她有益建议的同伴探险者。

“你尝试过分布式鼻吗？”

“很遗憾。我每年春天都会对花粉过敏。”

在解决初始的困惑之后，我们的英雄意识到其他探险者已经走过了这条道路。太好了！

她快速浏览了一篇紧张的叙事介绍，坦白地说，觉得它相当陈词滥调。跳到书籍的可操作部分，她找到了快速的解决方案。这正是他们需要的工具。

只需最小的努力，测试套件就被分布到了4台机器上。测试时间被大幅缩短，测试套件得以保存。在思考未来时，我们的英雄意识到她将永远不会再次面对关于可扩展性的不确定性。她只需添加更多机器即可！

测试套件的可扩展性得到保障，我们的英雄继续面对许多其他的冒险和挑战。但再也没有什么能像未经测试的代码的压迫那样，接近于抹去他们的核心。

## 为什么选择分布式鼻？

使用两个测试标志，水平扩展您的测试到无限数量的机器上。

## 安装

1. 获取项目源代码并安装

   $ pip install distributed-nose

## 使用

在第一台机器上运行一半的测试，在另一台机器上运行另一半

机器1

$ nosetests –nodes 2 –node-number 1 long_test_suite

机器2

$ nosetests –nodes 2 –node-number 2 long_test_suite

或者，您可以使用环境变量：* NOSE_NODES * NOSE_NODE_NUMBER

### 临时禁用测试分发

如果您正在使用环境变量来控制测试分发，有时您可能仍然想要运行一个单独的测试。无需更改环境变量，您可以使用 –distributed-disabled 标志。

$ export NOSE_NODES=2; $ export NOSE_NODE_NUMBER=1; $ nosetests –distributed-disabled long_test_suite

## 分发算法

为了确定哪个节点运行哪个测试，分布式鼻依赖于 [hash_ring](https://github.com/Doist/hash_ring) 库的一致性哈希实现。

默认情况下，测试会被单独哈希到环中。这导致分布最均匀，如果所有测试的运行时间相同，速度最快。然而，它会重复类设置/拆除工作。如果这很昂贵，您可能想要使用 –hash-by-class 或设置 NOSE_HASH_BY_CLASS；这将使同一类别的测试哈希到相同的节点。

## 运行测试套件

测试套件需要nose，可以通过 setup.py 运行

# python setup.py nosetests

## 它很棒吗？

是的。越来越棒。