什么是良好的代码测试比率?

时间:2022-09-06 18:47:01

I am using RSpec for writing tests.

我正在使用RSpec编写测试。

What do you think, is a good Code to Test Ratio?

你怎么看,这是一个很好的代码测试比率?

5 个解决方案

#1


6  

Code to Test Ratio is a bit of a misleading statistic. A much better method is to use rcov, you can easily use it by running rake spec:rcov

代码测试比率是一个误导性的统计数据。一个更好的方法是使用rcov,你可以通过运行rake spec:rcov轻松使用它

Whilst 100% code coverage is sometimes held up as an absolute target, you quickly run into the law of diminishing returns. Personally I aim for 90% code coverage in all production code; even though this is mainly arbitrary I find it much easier to have a target number to aim for.

虽然100%的代码覆盖率有时被视为绝对目标,但您很快就会遇到收益递减规律。我个人的目标是在所有生产代码中实现90%的代码覆盖率;尽管这主要是武断的,但我发现要设定一个目标号码要容易得多。

#2


4  

A good test to code ratio is one that allows you to feel confident in the code you have written and also allows you to refactor with confidence you will know what you area ffecting in the rest of your application. I have had test ratios ranging from 1:1.5 to 1:2.5 or so, it can really vary depending the complexity of your application.

对代码比率进行良好测试可以让您对自己编写的代码充满信心,也可以让您放心地重构,了解您在应用程序的其余部分中所遇到的区域。我的测试比率从1:1.5到1:2.5左右,它可以根据您的应用程序的复杂程度而变化。

#3


3  

We're talking about opinions at the moment. A good code-to-test ratio is one where your code is covered to the extent that it needs to be to allow both confidence in what is written and confidence that, when you are refactoring, you will know what is breaking all around you.

我们现在正在谈论意见。良好的代码与测试比率是指您的代码所覆盖的程度,以满足您对所写内容的信心和信心,当您进行重构时,您将知道什么在打破您周围。

Numbers are good, but putting too much stock in them can be just as dangerous.

数字很​​好,但在它们中放入过多的库存可能同样危险。

#4


3  

My goal is no untested code revealed by rcov and heckle. When you get all the coverage you can get with rcov, then you can run the code through heckle. Heckle modifies your code and shows you which modifications were not caught by tests.

我的目标是没有经过rcov和heckle揭示的未经测试的代码。当你获得rcov可以获得的所有覆盖范围时,你可以通过heckle运行代码。 Heckle会修改您的代码,并向您显示测试未捕获的修改。

rspec knows about heckle. After installing the heckle gem: "spec foo_spec.rb -H Foo". Oh, and if you get a bizarre error, install version 1.2.2 of ruby2ruby instead of 1.2.4.

rspec知道heckle。安装heckle gem之后:“spec foo_spec.rb -H Foo”。哦,如果你得到一个奇怪的错误,安装ruby2ruby版本1.2.2而不是1.2.4。

Here's heckle complaining about a function I thought I had fully specified:

这是heckle抱怨我认为我已经完全指定的函数:

The following mutations didn't cause test failures:

--- original
+++ mutation
 def model_matches?(substring)
-  s = substring.gsub(/\./, ".")
+  s = substring.gsub(/\033!\032\002l\}\?V\010d\}\r\-\fyg,a\*jFT\003_"ga\016\020ufN\0066/, ".")
   s = substring.gsub(/\*/, ".*")
   s = "^#{s}$"
   Regexp.new(s, "i").=~(@model)
 end

--- original
+++ mutation
 def model_matches?(substring)
-  s = substring.gsub(/\./, ".")
+  s = substring.gsub(/\./, "\023GA3w+h-#z$?I;a\"k0n^r$\005io#l\023H1M{\034m")
   s = substring.gsub(/\*/, ".*")
   s = "^#{s}$"
   Regexp.new(s, "i").=~(@model)
 end

--- original
+++ mutation
 def model_matches?(substring)
-  s = substring.gsub(/\./, ".")
+  s = nil
   s = substring.gsub(/\*/, ".*")
   s = "^#{s}$"
   Regexp.new(s, "i").=~(@model)
 end

--- original
+++ mutation
 def model_matches?(substring)
   s = substring.gsub(/\./, ".")
   s = substring.gsub(/\*/, ".*")
   s = "^#{s}$"
-  Regexp.new(s, "i").=~(@model)
+  Regexp.new(s, "v\022").=~(@model)
 end

How cool is that?

多么酷啊?

The only things I've found that are truly difficult to get full test coverage for are tests involving concurrency, esp. race conditions. Trying to prove that a mutex or a critical section must be in place can be difficult. Sometimes you can do it. Sometimes, you just have to shrug your shoulders, put in the line of code you don't know how to test, and move on.

我发现的唯一真正难以获得完整测试覆盖率的是涉及并发的测试,尤其是。竞争条件。试图证明互斥锁或临界区必须到位可能很困难。有时候你可以做到。有时,你只需要耸耸肩膀,放入你不知道如何测试的代码行,然后继续前进。

#5


1  

It varies. Simple code I'd expect as much test code as production code. Complicated code can easily deserve twice as much test code. Do Test Driven Development and won't have to worry about the ratio since everything in the code was driven by a test and that is what is important.

它有所不同。简单的代码我希望测试代码与生产代码一样多。复杂的代码很容易得到两倍的测试代码。做测试驱动开发并且不必担心比率,因为代码中的所有内容都是由测试驱动的,这才是重要的。

#1


6  

Code to Test Ratio is a bit of a misleading statistic. A much better method is to use rcov, you can easily use it by running rake spec:rcov

代码测试比率是一个误导性的统计数据。一个更好的方法是使用rcov,你可以通过运行rake spec:rcov轻松使用它

Whilst 100% code coverage is sometimes held up as an absolute target, you quickly run into the law of diminishing returns. Personally I aim for 90% code coverage in all production code; even though this is mainly arbitrary I find it much easier to have a target number to aim for.

虽然100%的代码覆盖率有时被视为绝对目标,但您很快就会遇到收益递减规律。我个人的目标是在所有生产代码中实现90%的代码覆盖率;尽管这主要是武断的,但我发现要设定一个目标号码要容易得多。

#2


4  

A good test to code ratio is one that allows you to feel confident in the code you have written and also allows you to refactor with confidence you will know what you area ffecting in the rest of your application. I have had test ratios ranging from 1:1.5 to 1:2.5 or so, it can really vary depending the complexity of your application.

对代码比率进行良好测试可以让您对自己编写的代码充满信心,也可以让您放心地重构,了解您在应用程序的其余部分中所遇到的区域。我的测试比率从1:1.5到1:2.5左右,它可以根据您的应用程序的复杂程度而变化。

#3


3  

We're talking about opinions at the moment. A good code-to-test ratio is one where your code is covered to the extent that it needs to be to allow both confidence in what is written and confidence that, when you are refactoring, you will know what is breaking all around you.

我们现在正在谈论意见。良好的代码与测试比率是指您的代码所覆盖的程度,以满足您对所写内容的信心和信心,当您进行重构时,您将知道什么在打破您周围。

Numbers are good, but putting too much stock in them can be just as dangerous.

数字很​​好,但在它们中放入过多的库存可能同样危险。

#4


3  

My goal is no untested code revealed by rcov and heckle. When you get all the coverage you can get with rcov, then you can run the code through heckle. Heckle modifies your code and shows you which modifications were not caught by tests.

我的目标是没有经过rcov和heckle揭示的未经测试的代码。当你获得rcov可以获得的所有覆盖范围时,你可以通过heckle运行代码。 Heckle会修改您的代码,并向您显示测试未捕获的修改。

rspec knows about heckle. After installing the heckle gem: "spec foo_spec.rb -H Foo". Oh, and if you get a bizarre error, install version 1.2.2 of ruby2ruby instead of 1.2.4.

rspec知道heckle。安装heckle gem之后:“spec foo_spec.rb -H Foo”。哦,如果你得到一个奇怪的错误,安装ruby2ruby版本1.2.2而不是1.2.4。

Here's heckle complaining about a function I thought I had fully specified:

这是heckle抱怨我认为我已经完全指定的函数:

The following mutations didn't cause test failures:

--- original
+++ mutation
 def model_matches?(substring)
-  s = substring.gsub(/\./, ".")
+  s = substring.gsub(/\033!\032\002l\}\?V\010d\}\r\-\fyg,a\*jFT\003_"ga\016\020ufN\0066/, ".")
   s = substring.gsub(/\*/, ".*")
   s = "^#{s}$"
   Regexp.new(s, "i").=~(@model)
 end

--- original
+++ mutation
 def model_matches?(substring)
-  s = substring.gsub(/\./, ".")
+  s = substring.gsub(/\./, "\023GA3w+h-#z$?I;a\"k0n^r$\005io#l\023H1M{\034m")
   s = substring.gsub(/\*/, ".*")
   s = "^#{s}$"
   Regexp.new(s, "i").=~(@model)
 end

--- original
+++ mutation
 def model_matches?(substring)
-  s = substring.gsub(/\./, ".")
+  s = nil
   s = substring.gsub(/\*/, ".*")
   s = "^#{s}$"
   Regexp.new(s, "i").=~(@model)
 end

--- original
+++ mutation
 def model_matches?(substring)
   s = substring.gsub(/\./, ".")
   s = substring.gsub(/\*/, ".*")
   s = "^#{s}$"
-  Regexp.new(s, "i").=~(@model)
+  Regexp.new(s, "v\022").=~(@model)
 end

How cool is that?

多么酷啊?

The only things I've found that are truly difficult to get full test coverage for are tests involving concurrency, esp. race conditions. Trying to prove that a mutex or a critical section must be in place can be difficult. Sometimes you can do it. Sometimes, you just have to shrug your shoulders, put in the line of code you don't know how to test, and move on.

我发现的唯一真正难以获得完整测试覆盖率的是涉及并发的测试,尤其是。竞争条件。试图证明互斥锁或临界区必须到位可能很困难。有时候你可以做到。有时,你只需要耸耸肩膀,放入你不知道如何测试的代码行,然后继续前进。

#5


1  

It varies. Simple code I'd expect as much test code as production code. Complicated code can easily deserve twice as much test code. Do Test Driven Development and won't have to worry about the ratio since everything in the code was driven by a test and that is what is important.

它有所不同。简单的代码我希望测试代码与生产代码一样多。复杂的代码很容易得到两倍的测试代码。做测试驱动开发并且不必担心比率,因为代码中的所有内容都是由测试驱动的,这才是重要的。