小编use*_*418的帖子

我刚刚在Qt 4.6中发现了排队连接的有趣行为:

首先排队连接:

connect(someSender, SIGNAL(completed()), this, SLOT(handleCompletion()), Qt::QueuedConnection)

然后someSender发送信号:

emit completed()

在接收信号之前(因为它在队列中),我断开信号:

disconnect(someSender, SIGNAL(completed()), this, SLOT(handleCompletion())

仍然,在下一个eventloop迭代时调用handleCompletion槽.我可以通过在正确的点使用someSender-> blockSignals(true)来防止这种情况发生,但是如果没有提及一些布尔标志来禁用插槽的功能,那就太糟糕了.

特别是,我感到惊讶的是Qt文档中没有提到这种行为(至少我没有找到).

最后一个问题:任何明智的方法来避免这种情况发生？

我们公司正在努力通过在自动化单元测试中实施最小功能覆盖来提高软件质量.这已经是一个很好的起点,至少可以编写一些测试并使其自动化(尽管最好选择分支或决策).

我主要担心的是在本政策投入使用后将要编写的测试结果.我经常看到这样的规则导致大量的空测试(即没有任何断言)或一些维护噩梦的集成测试.我发现以下SO问题接近主题,但这些问题更多地集中在覆盖百分比上:

代码覆盖的陷阱

单元测试的合理代码覆盖率是多少(以及为什么)？

相反,我想得到帮助或洞察,我们如何避免可怕的测试质量.所以这里有几个最糟糕的单元测试no-nos以及我已经想到的避免它们的内容:

1)空测试

• 代码审查测试代码也
• 当我们使用测试框架时,断言是通过使用FW宏完成的.也许我们可以编写一些工具来计算测试中每个类方法调用的断言比率.不知道,什么是足够好的比例.

2)集成测试

• 再次审查
• 也许是一些代码分析工具,用于检查测试代码与生产代码的依赖关系.测试类应该对测试系统的其他类(测试中的一个除外)具有非常少的依赖性.

有很多团队,我并不完全相信团队内部的评论在所有情况下都足够了.因此,我对自动化质量保证的方式更感兴趣.

TIA,lutku