在多台机器上分发你的鼻子测试，无需麻烦
distributed-nose的Python项目详细描述
#分布式nose将测试分布在多个节点上，无需麻烦
##tldr
###之前
机器1：
< Buff行情> $nosetests长测试套件 … 在401.109s中进行1312次测试机器2：
< Buff行情> $echo"我很无聊：（" 我很无聊：（ $uptime awk-f'平均加载：'{print'加载：'$2}' 负载：0.00、0.00、0.00显影剂：
< Buff行情> $google chrome http://news.ycombinator.com" rel="nofollow">http://news.ycombinator.com###之后
机器1：
< Buff行情> $export nose_nodes=2； $export nose_node_number=1； $nosetests长测试套件 … 在220.502秒内运行660次测试机器2：
< Buff行情> $echo"我感到被爱" 我感到被爱 $export nose_nodes=2； $export nose_node_number=2； $nosetests长测试套件 … 在214.007s中运行652个测试##测试套件的传奇
###压制未经测试的代码
你的测试套件有英雄也有坏蛋， 它的胜利和失误。 像许多其他故事一样， 从一个孤独的英雄开始。 大学毕业， 她加入了一个快乐的软件工程冒险家乐队。 在管理层的领导和众多人物的支持下， 他们建造了普通人喜欢和需要的东西。
慢慢地，事情开始改变。 结构不良且强耦合的代码潜入代码库， 使改变变得越来越困难 允许狡猾的虫子出现。 党员们开始经常破坏工程的不同部分， 范围太大，一个人不能很快地测量。 禁区变成禁区， 因为龙和未知的东西会夺走所有试图进入的人。
在这一切中，我们的英雄怀着沉重的心情看着。 对这个未经测试的代码库该怎么办？ 她当然不能一个人改变一切吗？ 她只是一个人！
最后，每天的挣扎使她筋疲力尽。
"够了就够了！"
"她下定决心，高谈阔论如何最好地罢工。 反对未经测试的代码的压迫。
"我将编写测试，并将它们提交给源代码管理！"
" 她说， 理解工作代码是最好的论证。###以鼻子为燃料的和平
有条不紊地挥舞和教学[鼻子]（https://github.com/nose-devs/nose）， 她从内部招募人员组成一支志同道合的开发队伍。 他们是TDD的团契 他们决心要成功。 测试是在大量高值代码中提交的！
团契的壮举激起了其他开发者的兴奋。 另一个英雄认为如果进行一些测试是好的， 那么一直运行所有的测试就更好了！ 戴着系统管理的帽子， 他利用额外的服务器资源 一个连续的集成过程诞生了。
然而，我们的英雄对他们的成功过于自信。 很少试图证明这种做法是正当的， 写测试所花的时间要花在管理上。 管理层的监督行动压垮了我们刚刚起步的奖学金。
###管理层的后推
"如果你有时间写测试， 我给你的肯定不够！"
"他们咆哮， 用最危险的武器威胁： 消极的、咄咄逼人的意见分歧。
我们的英雄再次鼓起勇气， 通过努力， 用高质量的利剑勇敢地战胜管理层的反对。 和平与生产力的新时代开始了 这个项目也很成功。
但这种和平不会持久。 缓慢的测试运行的幽灵笼罩着我们的英雄。 很快，测试失败就被忽略了。 开发人员并没有等待测试完成！ 测试套件会衰退。
###多进程到达
开发人员抱怨不已，管理层自由地向i-tell-you-sos游说。 考试前的黑暗时代即将重现。
"我会加速你R测试！"
"一个声音呼喊着。 又是我们的英雄， 发誓要从根本上打击腐败。
翻阅古文， 她很快发现 [多进程]（http://nose.readthedocs.org/en/latest/plugins/multiprocess.html" rel="nofollow">http://nose.readthedocs.org/en/latest/plugins/multiprocess.html）。
"这将使我们摆脱单核束缚。"
她自信地宣称。 几小时后， 她的8核机器轻快地通过了测试。 很快，ci服务器上就开始使用多进程了， 测试速度向前加速。
在试验区一切正常！ 她的开发伙伴举办了一个休息室聚会 为了她。 python meetup说流水 TDD再次受到所有人的喜爱。
就像以前的和平一样， 这也是暂时的， 因为增加更多的核心是昂贵的。 快进几个分数测试， 以及曾经快速的测试套件 经常让这个健壮的多核ci服务器屈服。
###分布绝望
记住实现多进程的易用性， 我们的英雄知道演习。 她只需将测试分发到多个服务器上！ 同样的古籍也被人们满怀信心地查阅， 解决方案似乎显而易见。
但是等等！简单的指南在哪里？
我们的英雄不是巫师。 她无法破解分布式系统的古老卷轴。 她没有时间接受正规的巫师训练， 所涉及的运动部件数量令人难以置信。
绝望开始了，曾经快速的甜蜜考验变得越来越慢。 我们冒险者的前景黯淡， 作为对加速测试本身的评估，显示了巨大的挑战。 有些人甚至建议完全放弃测试套件 对速度有了新的关注！
派系形成，党有分裂的危险！
###分布式鼻：可扩展的解决方案
"等一下。"
一个清晰的声音传了出来。 又是我们的英雄。
"为什么我们的测试人员需要沟通来协调？ 我们的memcached服务器需要相同级别的协调 轻松实现！"
"被一个念头的闪现逗乐， 她开始工作了。 她很坚定，把一大堆的书 [一致散列]（http://en.wikipedia.org/wiki/consistent\u hashing" rel="nofollow">http://en.wikipedia.org/wiki/consistent\u hashing）。 一旦解决方案在她脑子里清楚了， 她碰巧遇到了一个有好建议的冒险家伙伴。
"你试过分布式鼻子吗？"
""很不幸。 我对花粉过敏 每年春天我都会得到它。"
在最初的混乱解决之后， 我们的英雄明白了 其他冒险家已经走过这条路了。 万岁！
她迅速略过一段紧张的叙述性介绍， 坦白地说，这是一种衍生。 跳转到书中可操作的部分， 她很快就成功了。 这是他们的工具。
用最少的努力， 测试套件分布在4台机器上。 缩短了测试时间 测试套件已保存。 思考未来，我们的英雄意识到 她再也不会面临可扩展性的不确定性。 她总是能增加更多的机器！
确保了测试套件的可扩展性， 我们的英雄将继续面对许多其他的冒险和考验。 但再也不会有什么东西如此接近抹去它们的核心 作为未经测试代码的压迫。
##为什么要分布鼻子？
使用两个测试标志在不受限制的机器上水平缩放测试。
##安装
获取项目源并安装它
< Buff行情>$pip安装分布式nose
< > >
##用法
在一台机器上运行一半测试，在另一台机器上运行另一半测试：
机器1：
< Buff行情> $nosetests–nodes 2–node number 1 long_test_套件机器2：
< Buff行情> $nosetests–nodes 2–nodes number 2 long_test_套件或者，您可以使用环境ent变量： *鼻节点 *鼻子节点号
###暂时禁用测试分发
在使用环境变量的情况下 为了控制测试分布， 有时您可能仍然希望运行一次性测试。 与其摆弄环境变量， 您只需使用"Distributed Disabled"（分布式禁用）标志即可。
< Buff行情> $export nose_nodes=2； $export nose_node_number=1； $nosetests–分布式禁用长测试套件##分布算法
要确定哪个节点运行哪个测试， 分布式nose依赖于[hash_ring]（https://github.com/doist/hash_ring） 库的一致哈希实现。
默认情况下，测试将单独散列到环。 如果所有测试都具有相同的运行时，这将导致最均匀的分布和最佳的速度。 但是，它复制了类设置/拆卸工作。 如果代价很高，您可以使用–hash by class或设置nose_hash_by_class； 这将把同一类中的测试散列到同一节点。
##运行测试套件
测试套件需要nose，可以通过setup.py运行 < Buff行情> #python setup.py notests
##太棒了吗？
是的。越来越多。欢迎加入QQ群-->： 979659372
