Mocha: --order选项可用于随机测试订单？

嗯，不用工具就可以很容易地避免交叉测试的依赖

虽然to avoid cross-test dependencies without help of tooling很容易，但是在不注意的情况下在测试套件中添加这样的依赖关系也很容易。 测试套件中的错误通常会转换为被测系统中的错误。 这些bug很难被追踪，因为该代码被认为是经过测试的。

没有工具，就不可能测试是否缺少交叉测试依赖项。

@visionmedia ，请重新考虑。

+1 @yanovich。 我会使用输出种子号的随机顺序选项。 这在CI环境中将非常有用。

@visionmedia ，猫鼬模型提供了一个简单的交叉测试依赖示例。 mongoose.model 'User', UserSchema将模型添加到mongoose.models数组中。 因此，可以创建一个依赖于在mongoose.models中加载的用户模型的文件。 以Comment.find().populate('_user').exec(cb)为例。 如果用户测试在评论测试之前运行，则可以很好地执行，因为大概require('./models/user') （或其他价格）已将User模型加载到mongoose.models中。 但是，如果注释测试在用户测试之前执行，您将收到此错误Schema hasn't been registered for model "User" 。 当注释api在用户api之前运行并且注释文件不知道它具有跨文件依赖性时，这可能会在生产中发生。

如果测试文件具有require（'./ models / user'）（或其他内容）并且将用户加载到mongoose.models中，则测试仍可能存在生产问题。 但是，具有随机顺序将是发现此类潜在问题的一种更有用的工具。

我希望很好地阐明这一点。 期待听到您的想法。

抱歉，我认为这是主要的矫over过正，摩卡咖啡已足够膨胀。 如果有更多的兴趣，那么值得承担维护费用。

感谢您的考虑。

像代码中的大多数事情一样，知道的人很容易避免故意这样做。 避免无意间做起来比较困难。 而且，如果您不知道这甚至是个问题（例如，混合经验的团队），那么它很可能会发生:)

似乎有很多人对它感兴趣（很多人认为这是minitest的最佳功能之一）。 如果合并，我很乐意实现。

+1感兴趣。

会很高兴！ 我发现重命名文件名导致测试失败。

+1这很重要

：+1：

：+1：

+1这是一个很大的缺陷。

rspec的语义非常扎实：您可以传递订单种子，也可以随机选择它。 如果随机选择种子，则将其打印出来，因此很容易复制。

避免交叉测试的依赖关系通常不是那么容易。 有时是由于无法预料的全球互动，有时是出于方便。 我怀疑如果将订单随机分配，超过50％的使用Mocha的项目会看到测试失败。 这是几个似乎依赖于测试执行顺序的示例：

https://github.com/visionmedia/mocha/blob/master/test/hook.async.js#L95
https://github.com/visionmedia/superagent/blob/master/test/node/not-modified.js#L31

这两个在http://visionmedia.github.io/mocha/上被列为示例测试套件，我没有花很多时间来寻找问题。

我将重新打开它。 我认为这会有所帮助。 尽管有很多方法可以确定不使用工具的交叉测试部门，但如果我们可以实现自动化，则可以节省人员时间。

玩弄了一下之后，由于套件的分层性质，它显得不平凡。 通过递归进入套件来运行测试。 要随机运行_Tests_，我们必须枚举它们，将它们随机化，然后向后工作。

这将导致before()和after() Hook变得毫无意义，因为它们将在Suite中的每个_n_测试中被执行_n_次（或更确切地说，在_worst_情况下，但只有当我们小心翼翼时） ），因为我们不断更改上下文。 听起来会招致性能损失。

使用随机种子和报告自动生成的种子似乎很简单，但是，报告者可能需要了解此信息，因此需要在报告者中实施。

当然，我假设我在这里描述的是所要的。 这样的功能需要规范。

其他选项包括“随机化套件”或“套件中的随机测试”或两者的某种组合。 实际上，这意味着，一旦进入describe() _ describe()块_B_中执行测试，直到_A_中的所有测试都已运行（看起来是一个更直接的实现，并且不会导致before() / after()谦卑感。

我（并且我认为其他人）要求的是最简单的选择：

• 在最低级别对测试进行随机化：在一个描述块内； 随机播放“ it”语句。
• 随机化顶级套件的顺序（或随机化加载文件的顺序）

我认为在中级水平上改组没有太大价值。

当然是黑客，但适用于最低级别的https://github.com/syrnick/mocha/compare/random_order?expand=1&w=0

mocha - fail
connect - pass
superagent - fail
express - pass** 
websocket.io - pass (can't tell for sure)

**无论哪种方式，我在整个测试套件的100次运行中都有2次间歇性故障。

好的，这确实很容易实现！

我正在为此寻找种子种子库。 使用pass选项。

会接受公关。

在接下来的几天中，我可能会清理该代码并调整测试套件。 下划线是否太依赖于此？ 我可能会使用类似以下的内容： http :

@boneskull，我支持您决定重新打开此文件。 ：+1：

其他选项包括“随机化套件”或“套件中的随机测试”或两者的某种组合。

对我来说似乎绰绰有余。 无需完全递归，枚举和随机播放。

很高兴听到这个消息。

我想知道rspec是否已处理递归洗牌？ 可能值得一看
在他们的代码？

2014年8月26日，星期二，Joshua Appelman [email protected]
写道：

@boneskull https://github.com/boneskull我支持您的决定
重新打开这个。 [image：：+1：]

其他选项包括“随机化套件”或“内部随机化测试
套件”或两者的某种组合。

对我来说似乎绰绰有余。 无需一路递归
列举和洗牌。

-
直接回复此电子邮件或在GitHub上查看
https://github.com/visionmedia/mocha/issues/902#issuecomment -53482124。

@syrnick我不想接受具有如此大依赖关系的PR，而是使用seedrandom 。 没有它，我不确定您将如何支持播种。 seedrandom允许您指定种子或不指定种子，如果不指定，它将返回种子。 然后我们可以将其显示给用户，并允许他们指定它，即RSpec。

@syrnick提醒您，如果您确实生成了种子，那么在不将其传递给记者的情况下，它们可能无法“显示”。 我对报告体系结构不是很熟悉，所以我不能肯定地告诉您或者该怎么做...

+1

我没有研究实现，但是默认情况下+1对随机排序的测试执行非常重要。

@syrnick，如果您打算这样做，请告诉我，谢谢。

我很高兴这样做，但是我没有即时的预计到达时间。

：+1 :，你们还需要PR方面的帮助吗？

确实，似乎没有人开始从事这一工作。

首先，Fisher-Yates洗牌似乎可以在这里完成工作。

其次，我宁愿将--order random ， --order random-suites和--order default作为三个参数，以及一个可选的:<seed> 。

+1。 刚刚发现了一个错误，如果将测试随机化，该错误会在很久以前出现。 类似于RSpec支持它的方式。

以下代码说明了随机测试排序的有用性。 尽管有一些简单的示例，但这是我在TDD演示期间遇到的一个示例。 如果您颠倒测试顺序，则第一个测试将始终失败。

game.js：

var express = require('express');
app = exports.app = express();

var sum = 0;

app.post('/bowl/:pins', function(req,res) {
    var score = parseInt(req.params.pins);
    console.log('Bowled ' + score);
    sum += parseInt(req.params.pins);
});

app.get('/score', function(req,res) {
    console.log('Sum: ' + sum);
    res.send(sum + '');
});

app.listen(process.env.PORT || 3000);

测试\ gameTest.js：

var request = require('supertest'),
    should = require('should'),
    game = require('../game.js').app;

describe('a game of bowling', function() {
    describe('a gutter game', function() {
        it('should score 0', function(done){
            request(game).get('/score').expect(200, '0', done);
        });
    });

    describe('a single pin game', function() {
        it('should score 20', function(done){
            for(var i = 0; i < 20; i++) {
                request(game).post('/bowl/1').expect(200, done);
            }
            request(game).get('/score').expect(200, '20', done); 
        });
    });
});

我很想拥有这个。

：+1：

一旦涉及到一些全局变量（记住，这是Javascript），开始存根服务器调用以及在测试中从DOM中插入/删除内容，就很容易添加订单依赖性。 将测试顺序随机化将有助于更早发现这些问题，而不是后来发现。
：+1：

：+1：

：+1：

+1

默认情况下，随机订单以及可选的种子可以重新创建订单，这将是一个很棒的功能。

+1拥有它，以随机顺序运行时我的测试有时会失败...

同时，抢救Unix（不幸的是，不支持随机种子）：

mocha `ls -1 test/*.js | sort --random-sort `

正在搜寻摩卡以什么顺序运行测试并发现了这一点。 如果没有随机分组，默认的运行顺序是什么？ 测试始终以物理方式出现在文件中的顺序是什么？

：+1：

@danielabar是的，它们会按顺序出现在文件中。

@NicolasJacob好吧，顺便说一句，在某种程度上实际上是可能的。 :)

$ seq 10 | shuf --random-source=<(yes 2883)
1
7
3
4
6
2
10
5
9
8

https://github.com/bahmutov/rocha可以做到这一点。

@boneskull虽然这是一个老问题，但是PR Please标签仍然有效吗？ 如果是这样，我会在第二天左右得到一些帮助。

我认为，在最终尝试使Mocha核心保持最小化的过程中，团队可能不愿引入许多新功能。 Mocha的下一个主要发行版的目标是具有可插入的接口。

我是否建议仅使用https://github.com/bahmutov/rocha如果有效？

很棒的酱

可插拔接口是什么意思？ 是否可以通过此接口引入随机测试订单？

为功能请求+1

@sulabhjain ，之前和之后的支持者，请改用+1反应。

这个部门的进展。

为此功能+1

对于测试框架而言，这确实是最关键的功能，可帮助保持测试独立。 每个主要的JVM测试框架都具有此基本功能。

为此功能+1。 是的，很容易避免有足够的经验和/或独自工作来避免依赖测试，但这并非总是如此。

对于那些对此功能感兴趣的人，他们可以针对随机分支发送PR，以帮助完成剩余的工作。

为该功能+1。 非常感谢为此正在建立一个分支。

仍在等待这个:)）

这真的很有用。
@tj我知道当您与具有测试基本技能的人一起工作时，很容易避免测试依赖性，但是有时您需要接管开发团队，并且甚至可以与甚至不具备测试用例基本知识的人碰面。

实际上，当您接管现有项目并希望轻松检查一项测试是否与前一项测试相关时，这也很有用。

@boneskull太好了！ 此修复程序的状态如何？ 您需要任何帮助吗？

我只是想分享我的临时解决方案，用于以随机顺序运行mocha测试。 也许对某人有用。

mocha $(find tests/ -name *.spec.js | shuf)

不幸的是，这并没有在同一示例中混用测试示例，但这仍然非常聪明和方便！

+1支持此功能

这仍然摆在桌子上，但需要我注意

那么，这里实际上还剩下什么？ 我从哪里开始？

希望看到已实现的❤️

我刚刚找到了choma软件包，该软件包为Mocha提供了一个非常简单的插件，可以使测试套件和案例的顺序随机化。 替代rocha的好选择，前面已经提到过。 简单为我解决问题！

一种替代方法是并行运行测试：

• 业力（+摩卡或茉莉）-业力并行-目前不支持代码覆盖
• 摩卡-摩卡并行测试或mocha.parallel
• 开玩笑-默认情况下会这样做