问题标签 [codacy]

我的团队最近开始研究一个以前存在的完全用 ES6 编写的 Node 应用程序（在我们工作之前，它已经通过了几个不同的开发人员）。该应用程序使用 Mocha 和 Nyan 作为 Mocha 的报告程序进行了最低限度的单元测试。package.json 文件已经包含以下运行测试的命令：

作为我们部署周期的一部分，我们使用带有 Travis 和Codacy的 CI/CD 管道。因此，为了启用 Codacy 的“代码覆盖”部分，我需要对应用程序存储库和 package.json 文件进行一些更改。基本想法是让 Mocha 生成一个.lcov文件，然后在 Travis 构建脚本中将其通过管道传输到 Codacy。

在做了一些研究后，我将以下内容组合在一起以成功生成lcov文件：

问题是，我收到.lcov文件的 Codacy 解析错误。我查看了其他项目的 lcov 文件，我正在生成的文件中似乎有额外的数据。此处参考生成的 lcov 文件：

我观察到一些关于 npm 脚本（测试和构建测试）的事情：

• 测试工作正常，通知我 9 个测试通过
• 如果我在没有“--reporter nyan”的情况下运行构建测试，它会显示“未找到覆盖数据，请确保您的代码已正确检测”
• build-test 代码行中的所有内容似乎都是必要的。

老实说，我已经束手无策了。我不知道为什么.lcov文件有解析问题。我真正需要的是使用 mocha 和 mocha-lcov-reporter 来生成有效的.lcov文件。看起来它不应该那么困难。

感谢您提供的任何帮助。我很感激。

我有以下代码

我收到Codacy的警告：标准伪随机生成器不适用于安全/加密目的。

我应该重写这个函数以避免这样的警告。

I'm using the meteor-coverage package (version 1.1.4) with mocha (version 2.4.5_6) and meteor version 1.4.4.1 on Ubuntu 14.04 LTS. I have been able to produce very pretty test coverage reports, but it seems that for the client-side tests something is amiss. In order to send the coverage data to localhost:3000/coverage I have created a function called sendCoverage() which I import in my .tests.js files:

I call this function after a block of mocha tests:

Now, this produces test coverage reports in my localhost:3000/coverage page, but it seems as though it does not display the coverage properly. For example, I see that some statements are executed, but are highlighted in red and flagged as not covered. For example:

It seems as though the statements get executed 11 and 12 times, respectively. However, they are not flagged as being covered and in my reports the percentage of statement coverage reflects this.

Does anyone know what I may be doing wrong and/or have experience with client-side code coverage and the meteor-coverage package?

Thanks!

Post-solution edit

It seems I've got it working now. The percentages on Codacy match the percentages in my html report. Looking at the html report more closely, it seems the coverage numbers were correct after all. It was simply the drill down that was showing odd behavior. So, the conclusion is that it worked after all, but it took Codacy's second opinion to confirm this to me. My new approach will be to create lcov coverage reports with spacejam (see Ser's answer below) and export these to an external service like Codacy, Codecov or SonarQube.

Thanks Serut for the input!

我听说好的做法是使用一些东西来检查我的代码。我发现了一个叫做Codacy的东西。除了 TSLint 和 TSLint4 中的“预期空间缩进”之外，我了解所有内容。是因为我在项目中的身份是标签吗？如果是，我怎样才能改变这一规则？

Codacy显示问题

我在我的项目中使用Codacy，我收到一条警告，说我不应该使用稍后声明的变量，这是非常合乎逻辑的。但是，这对于构造函数应该可以正常工作。

这是我的主要文件结构：

在对象构造函数声明之前导出是否会出现任何问题？我应该将导出线移到构造函数下方吗？

我目前正在用 Javascript 开发一个小游戏，我正在使用Codacy来审查我的代码并帮助我清理它。

最常见的错误之一是通用对象注入接收器（安全/检测对象注入）。

当我尝试使用变量访问数组中的值时会发生这种情况。就像在这个例子中：

这function用于在屏幕上显示项目的值字符串。它接收一个可以是 0、1、2 或 3 的“值”并返回该值的字符串。

现在这是我的问题：

Codacy 告诉我var[var]应该禁止使用，因为它会导致安全问题，而且由于我对 Javascript 还比较陌生，所以我想知道为什么以及在这种情况下有哪些好的做法。

我有一个功能，它工作得很好，但代码检查表明这样做是不好的做法。我知道它甚至看起来不安全，但我无法想出另一种更好的方法。

在 Icycool 的建议之后，我想出了一些更容易接受的方法。我尝试使用 forEach 循环，但没有成功，所以我决定使用 fori。虽然它并不完美，但它现在可以做到：

Codacy js 测试给我一个安全的错误：

函数调用对象注入接收器（security/detect-object-injection）

对于下一个代码行：

为什么我不能[i]用于处理循环以及为什么它不安全？

在通过 codacy 审查一些代码时，Codacy 给出了以下代码的问题：

有以下解释：

为什么这是一个问题？

例如，使用基类作为第一个参数调用 super() 是错误的：

应该：

似乎希望我这样做：

或者也许是这样：

有人可以告诉我其中哪些是正确的，为什么这是首选行为？

作为参考，这里是我使用选项 2 找到的示例。

编辑：这是我的代码，因为它完全显示。这解释了我的错误：

为什么推荐这个？

I've put together a Maven-based project that uses Spek in the Junit 4 Runner for testing.

I configured the project in Codacy and got a useful suggestion to either document my public classes or reduce their visibility (great).

I've found that the Kotlin compiler seems to regard the tests as existing in a different module, which makes it very difficult to do effective unit testing given my project layout. The tests will not compile if the visibility of classes or interfaces are reduced to internal.

Please suggest a mechanism to fix this. Is it just not possible to use internal visibility modifier in this situation? Is there a useful compiler configuration or Spek configuration that can overcome the issue? I think the suggestion is indeed correct; I do not wish to document the classes because they are internal and may change in the future or the documentation is simply not worth the effort.