단위 테스트에 대한 합리적인 코드 커버리지 %는 무엇이며 그 이유는 무엇입니까? [닫은]
리포지토리 커밋에 대한 요구 사항으로도 단위 테스트에 대해 최소 백분율 코드 커버리지를 요구한다면 어떻게 될까요?
당신이 어떻게 당신의 대답에 도달했는지 설명 해주세요 (당신이 한 모든 것이 숫자를 고르기 만했다면, 그 모든 것을 혼자서 할 수 있었을 것입니다;)
Alberto Savoia의이 산문은 그 질문에 정확하게 대답합니다 (멋진 방식으로!) :
http://www.artima.com/forums/flat.jsp?forum=106&thread=204677
Testivus On Test Coverage
어느 날 아침 한 프로그래머가 위대한 스승에게 물었습니다.
“단위 테스트를 작성할 준비가되었습니다. 어떤 코드 커버리지를 목표로해야합니까?”
위대한 스승은 다음과 같이 대답했습니다.
"보장 범위에 대해 걱정하지 말고 좋은 테스트를 작성하십시오."
프로그래머는 미소를 지으며 절을하고 떠났습니다.
...
그날 늦게 두 번째 프로그래머가 같은 질문을했습니다.
위대한 스승은 끓는 물이 담긴 냄비를 가리키며 이렇게 말했습니다.
“그 냄비에 쌀 몇 알을 넣어야하나요?”
프로그래머는 당황한 표정으로 다음과 같이 대답했습니다.
“어떻게 말할 수 있겠습니까? 얼마나 많은 사람을 먹여야하는지, 얼마나 배가 고프는지, 어떤 다른 음식을 제공하는지, 얼마나 많은 쌀을 먹을 수 있는지 등에 달려 있습니다.”
“맞아요.”위대한 스승이 말했다.
두 번째 프로그래머는 미소를 지으며 절을하고 떠났습니다.
...
하루가 끝날 무렵, 세 번째 프로그래머가 와서 코드 커버리지에 대해 같은 질문을했습니다.
"80 퍼센트도 그 이하도 아닙니다!" 주인은 단호한 목소리로 대답하며 주먹을 탁자에 두드렸다.
세 번째 프로그래머는 미소를 지으며 절을하고 떠났습니다.
...
이 마지막 답장 후에 한 젊은 제자가 위대한 스승에게 다가갔습니다.
“대장님, 오늘 저는 코드 커버리지에 대한 동일한 질문에 세 가지 다른 답변으로 대답하는 것을 우연히 들었습니다. 왜?"
위대한 스승은 의자에서 일어났습니다.
“저와 함께 신선한 차를 마시고 그것에 대해 이야기합시다.”
그들이 컵에 뜨거운 녹차를 채운 후 위대한 스승은 대답하기 시작했습니다.
“첫 번째 프로그래머는 새롭고 막 테스트를 시작했습니다. 현재 그는 많은 코드와 테스트가 없습니다. 그는 갈 길이 멀다. 이 시점에서 코드 커버리지에 초점을 맞추는 것은 우울하고 쓸모가 없을 것입니다. 그는 테스트를 작성하고 실행하는 데 익숙해지는 것이 좋습니다. 그는 나중에 보험에 대해 걱정할 수 있습니다.”
“반면에 두 번째 프로그래머는 프로그래밍과 테스트에 모두 경험이 많습니다. 내가 냄비에 쌀 몇 알을 넣어야하는지 물어 보면서 대답했을 때, 나는 그녀가 필요한 테스트의 양이 여러 요인에 따라 달라진다는 것을 깨닫도록 도왔고 그녀는 그 요인을 저보다 더 잘 알고 있습니다. 결국 그녀의 코드입니다. . 단 하나의 단순한 대답은 없으며 그녀는 진실을 다루고 그것에 대해 일할만큼 똑똑합니다.”
"그렇군요."라고 젊은 견습생이 말했다. "하지만 간단한 대답이 하나도 없다면 왜 세 번째 프로그래머에게 '80 % 이하 '라고 대답 했습니까?"
위대한 스승은 너무 세게 웃으며 그의 배는 그가 녹차보다 더 많이 마셨다는 증거로 위아래로 흔들렸다.
"세 번째 프로그래머는 단순한 대답이없는 경우에도 간단한 대답 만 원하고… 어차피 따라 가지 않습니다."
어린 견습생과 그 리즐링 한 거장은 명상적인 침묵 속에서 차를 마 셨습니다.
코드 커버리지는 모든 기능을 100 % 테스트하는 대신 100 % 커버리지가 목표 인 경우 잘못된 메트릭입니다.
- 모든 라인을 한 번 치면 100 %를 얻을 수 있습니다. 그러나 해당 행에 해당하는 특정 시퀀스 (논리적 경로) 테스트를 놓칠 수 있습니다.
- 100 %를 얻을 수는 없었지만 여전히 모든 80 % / freq 사용 코드 경로를 테스트했습니다. 모든 'ExceptionTypeX 던지기'또는 유사한 방어 프로그래밍 가드를 테스트하는 테스트를 갖는 것은 '필수'가 아닌 '갖는 것이 좋다'입니다.
따라서 자신이나 개발자가 철저하게 코드를 통해 모든 경로를 다루도록 신뢰하십시오. 실용적이어야하며 마법의 100 % 적용 범위를 쫓지 마십시오. 코드를 TDD하면 보너스로 90 % 이상의 보상을받을 수 있습니다. 코드 커버리지를 사용하여 놓친 코드 덩어리를 강조 표시합니다 (TDD를 사용하는 경우에는 발생하지 않습니다. 테스트를 통과하기 위해 코드를 작성하기 때문입니다. 파트너 테스트 없이는 코드가 존재할 수 없습니다.)
코드 커버리지는 훌륭하지만 기능 커버리지는 훨씬 더 좋습니다. 나는 내가 쓰는 모든 한 줄을 다루는 것을 믿지 않습니다. 그러나 저는 제가 제공하고자하는 모든 기능에 대해 100 % 테스트 범위를 작성한다고 믿습니다 (저와 함께 제공되고 회의 중에 논의되지 않은 추가 멋진 기능에 대해서도).
테스트에서 다루지 않는 코드가 있는지는 신경 쓰지 않지만, 코드를 리팩토링하고 결국 다른 행동을하게된다면 신경 쓸 것입니다. 따라서 100 % 기능 범위가 유일한 목표입니다.
받아 들여진 대답은 좋은 지적을합니다. 모든 프로젝트에 대한 표준으로 이해되는 단일 숫자는 없습니다. 그러한 표준이 필요하지 않은 프로젝트가 있습니다. 제 생각에 받아 들여진 대답이 부족한 부분은 주어진 프로젝트에 대해 어떻게 그 결정을 내릴 수 있는지 설명하는 것입니다.
나는 그렇게 할 것입니다. 나는 테스트 엔지니어링 전문가가 아니며 더 많은 정보에 입각 한 답변을 보게되어 기쁩니다.
코드 커버리지 요구 사항을 설정하는 경우
첫째, 애초에 그러한 표준을 부과하고 싶은 이유는 무엇입니까? 일반적으로 프로세스에 경험적 신뢰를 도입하려는 경우. "경험적 신뢰"란 무엇을 의미합니까? 글쎄, 진짜 목표 정확성 . 대부분의 소프트웨어에서 우리는 모든 입력에서 이것을 알 수 없으므로 코드가 잘 테스트 되었다고 말하는 것에 만족합니다 . 이것은 더 잘 알지만 여전히 주관적인 표준입니다. 당신이 그것을 만났는지 아닌지에 대해 항상 토론 할 수 있습니다. 이러한 논쟁은 유용하고 발생해야하지만 불확실성도 드러냅니다.
코드 커버리지 는 객관적인 측정입니다. 커버리지 보고서를 보면 표준이 충족되었는지 여부에 대한 모호함이 없습니다. 정확성을 증명합니까? 전혀 그렇지는 않지만 코드가 얼마나 잘 테스트되었는지에 대한 명확한 관계가 있으며, 이는 코드의 정확성에 대한 신뢰를 높이는 최선의 방법입니다. 코드 커버리지는 우리가 관심을 갖는 측정 할 수없는 특성의 측정 가능한 근사치입니다.
경험적 표준이 가치를 더할 수있는 몇 가지 특정 사례 :
- 이해 관계자를 만족시키기 위해. 많은 프로젝트에서 소프트웨어의 일상적인 개발에 관여하지 않을 수있는 소프트웨어 품질에 관심이있는 다양한 행위자들 (관리자, 기술 책임자 등)이 있습니다. "우리는 모든 것을 작성할 것입니다. 우리가 정말로 필요로하는 테스트 "는 설득력이 없습니다. 그들은 전적으로 신뢰할 필요가 있거나 지속적인 면밀한 감독으로 검증해야합니다 (기술적 이해가 있다고 가정). 측정 가능한 표준을 제공하고 실제 목표에 합리적으로 근접하는 방법을 설명하는 것이 더 좋습니다.
- 팀 행동을 정상화합니다. 이해 관계자는 제쳐두고 여러 사람이 코드와 테스트를 작성하는 팀에서 작업하는 경우 "잘 테스트 된"것으로 간주되는 항목에 대한 모호성의 여지가 있습니다. 모든 동료가 어떤 수준의 테스트가 충분한 지 같은 생각을 가지고 있습니까? 아마 아닐 것입니다. 이것을 어떻게 조정합니까? 모두 동의 할 수있는 측정 항목을 찾아 합리적인 근사치로 받아들입니다. 예를 들어 리드가 주니어 개발자를 직접 감독하지 않을 수있는 대규모 팀에서 특히 유용합니다. 신뢰의 네트워크도 중요하지만 객관적인 측정이 없으면 모든 사람이 선의로 행동하더라도 그룹 행동이 일관성이 없게되기 쉽습니다.
- 자신을 정직하게 유지하십시오. 프로젝트에 대한 유일한 개발자이자 유일한 이해 관계자이더라도 소프트웨어에 대한 특정 특성을 염두에두고있을 수 있습니다. 소프트웨어가 얼마나 잘 테스트되었는지 (작업이 필요함)에 대해 지속적으로 주관적인 평가를하는 대신 코드 커버리지를 합리적인 근사치로 사용하고 기계가이를 측정하도록 할 수 있습니다.
사용할 메트릭
코드 커버리지는 단일 메트릭이 아닙니다. 적용 범위를 측정하는 방법에는 여러 가지가 있습니다. 표준을 정할 수있는 것은 해당 표준을 사용하여 충족시키는 것에 따라 다릅니다.
표준을 설정하는 데 사용할 수있는 경우의 예로 두 가지 일반적인 메트릭을 사용하겠습니다.
- Statement coverage: What percentage of statements have been executed during testing? Useful to get a sense of the physical coverage of your code: How much of the code that I have written have I actually tested?
- This kind of coverage supports a weaker correctness argument, but is also easier to achieve. If you're just using code coverage to ensure that things get tested (and not as an indicator of test quality beyond that) then statement coverage is probably sufficient.
- Branch coverage: When there is branching logic (e.g. an
if), have both branches been evaluated? This gives a better sense of the logical coverage of your code: How many of the possible paths my code may take have I tested?- This kind of coverage is a much better indicator that a program has been tested across a comprehensive set of inputs. If you're using code coverage as your best empirical approximation for confidence in correctness, you should set standards based on branch coverage or similar.
There are many other metrics (line coverage is similar to statement coverage, but yields different numeric results for multi-line statements, for instance; conditional coverage and path coverage is similar to branch coverage, but reflect a more detailed view of the possible permutations of program execution you might encounter.)
What percentage to require
Finally, back to the original question: If you set code coverage standards, what should that number be?
Hopefully it's clear at this point that we're talking about an approximation to begin with, so any number we pick is going to be inherently approximate.
Some numbers that one might choose:
- 100%. You might choose this because you want to be sure everything is tested. This doesn't give you any insight into test quality, but does tell you that some test of some quality has touched every statement (or branch, etc.) Again, this comes back to degree of confidence: If your coverage is below 100%, you know some subset of your code is untested.
- Some might argue that this is silly, and you should only test the parts of your code that are really important. I would argue that you should also only maintain the parts of your code that are really important. Code coverage can be improved by removing untested code, too.
- 99% (or 95%, other numbers in the high nineties.) Appropriate in cases where you want to convey a level of confidence similar to 100%, but leave yourself some margin to not worry about the occasional hard-to-test corner of code.
- 80%. I've seen this number in use a few times, and don't entirely know where it originates. I think it might be a weird misappropriation of the 80-20 rule; generally, the intent here is to show that most of your code is tested. (Yes, 51% would also be "most", but 80% is more reflective of what most people mean by most.) This is appropriate for middle-ground cases where "well-tested" is not a high priority (you don't want to waste effort on low-value tests), but is enough of a priority that you'd still like to have some standard in place.
I haven't seen numbers below 80% in practice, and have a hard time imagining a case where one would set them. The role of these standards is to increase confidence in correctness, and numbers below 80% aren't particularly confidence-inspiring. (Yes, this is subjective, but again, the idea is to make the subjective choice once when you set the standard, and then use an objective measurement going forward.)
Other notes
The above assumes that correctness is the goal. Code coverage is just information; it may be relevant to other goals. For instance, if you're concerned about maintainability, you probably care about loose coupling, which can be demonstrated by testability, which in turn can be measured (in certain fashions) by code coverage. So your code coverage standard provides an empirical basis for approximating the quality of "maintainability" as well.
My favorite code coverage is 100% with an asterisk. The asterisk comes because I prefer to use tools that allow me to mark certain lines as lines that "don't count". If I have covered 100% of the lines which "count", I am done.
The underlying process is:
- I write my tests to exercise all the functionality and edge cases I can think of (usually working from the documentation).
- I run the code coverage tools
- I examine any lines or paths not covered and any that I consider not important or unreachable (due to defensive programming) I mark as not counting
- I write new tests to cover the missing lines and improve the documentation if those edge cases are not mentioned.
This way if I and my collaborators add new code or change the tests in the future, there is a bright line to tell us if we missed something important - the coverage dropped below 100%. However, it also provides the flexibility to deal with different testing priorities.
I'd have another anectode on test coverage I'd like to share.
We have a huge project wherein, over twitter, I noted that, with 700 unit tests, we only have 20% code coverage.
Scott Hanselman replied with words of wisdom:
Is it the RIGHT 20%? Is it the 20% that represents the code your users hit the most? You might add 50 more tests and only add 2%.
Again, it goes back to my Testivus on Code Coverage Answer. How much rice should you put in the pot? It depends.
For a well designed system, where unit tests have driven the development from the start i would say 85% is a quite low number. Small classes designed to be testable should not be hard to cover better than that.
It's easy to dismiss this question with something like:
- Covered lines do not equal tested logic and one should not read too much into the percentage.
True, but there are some important points to be made about code coverage. In my experience this metric is actually quite useful, when used correctly. Having said that, I have not seen all systems and i'm sure there are tons of them where it's hard to see code coverage analysis adding any real value. Code can look so different and the scope of the available test framework can vary.
Also, my reasoning mainly concerns quite short test feedback loops. For the product that I'm developing the shortest feedback loop is quite flexible, covering everything from class tests to inter process signalling. Testing a deliverable sub-product typically takes 5 minutes and for such a short feedback loop it is indeed possible to use the test results (and specifically the code coverage metric that we are looking at here) to reject or accept commits in the repository.
When using the code coverage metric you should not just have a fixed (arbitrary) percentage which must be fulfilled. Doing this does not give you the real benefits of code coverage analysis in my opinion. Instead, define the following metrics:
- Low Water Mark (LWM), the lowest number of uncovered lines ever seen in the system under test
- High Water Mark (HWM), the highest code coverage percentage ever seen for the system under test
New code can only be added if we don't go above the LWM and we don't go below the HWM. In other words, code coverage is not allowed to decrease, and new code should be covered. Notice how i say should and not must (explained below).
But doesn't this mean that it will be impossible to clean away old well-tested rubbish that you have no use for anymore? Yes, and that's why you have to be pragmatic about these things. There are situations when the rules have to be broken, but for your typical day-to-day integration my experience it that these metrics are quite useful. They give the following two implications.
Testable code is promoted. When adding new code you really have to make an effort to make the code testable, because you will have to try and cover all of it with your test cases. Testable code is usually a good thing.
Test coverage for legacy code is increasing over time. When adding new code and not being able to cover it with a test case, one can try to cover some legacy code instead to get around the LWM rule. This sometimes necessary cheating at least gives the positive side effect that the coverage of legacy code will increase over time, making the seemingly strict enforcement of these rules quite pragmatic in practice.
And again, if the feedback loop is too long it might be completely unpractical to setup something like this in the integration process.
I would also like to mention two more general benefits of the code coverage metric.
Code coverage analysis is part of the dynamic code analysis (as opposed to the static one, i.e. Lint). Problems found during the dynamic code analysis (by tools such as the purify family, http://www-03.ibm.com/software/products/en/rational-purify-family) are things like uninitialized memory reads (UMR), memory leaks, etc. These problems can only be found if the code is covered by an executed test case. The code that is the hardest to cover in a test case is usually the abnormal cases in the system, but if you want the system to fail gracefully (i.e. error trace instead of crash) you might want to put some effort into covering the abnormal cases in the dynamic code analysis as well. With just a little bit of bad luck, a UMR can lead to a segfault or worse.
People take pride in keeping 100% for new code, and people discuss testing problems with a similar passion as other implementation problems. How can this function be written in a more testable manner? How would you go about trying to cover this abnormal case, etc.
And a negative, for completeness.
- In a large project with many involved developers, everyone is not going to be a test-genius for sure. Some people tend to use the code coverage metric as proof that the code is tested and this is very far from the truth, as mentioned in many of the other answers to this question. It is ONE metric that can give you some nice benefits if used properly, but if it is misused it can in fact lead to bad testing. Aside from the very valuable side effects mentioned above a covered line only shows that the system under test can reach that line for some input data and that it can execute without hanging or crashing.
If this were a perfect world, 100% of code would be covered by unit tests. However, since this is NOT a perfect world, it's a matter of what you have time for. As a result, I recommend focusing less on a specific percentage, and focusing more on the critical areas. If your code is well-written (or at least a reasonable facsimile thereof) there should be several key points where APIs are exposed to other code.
Focus your testing efforts on these APIs. Make sure that the APIs are 1) well documented and 2) have test cases written that match the documentation. If the expected results don't match up with the docs, then you have a bug in either your code, documentation, or test cases. All of which are good to vet out.
Good luck!
Many shops don't value tests, so if you are above zero at least there is some appreciation of worth - so arguably non-zero isn't bad as many are still zero.
In the .Net world people often quote 80% as reasonble. But they say this at solution level. I prefer to measure at project level: 30% might be fine for UI project if you've got Selenium, etc or manual tests, 20% for the data layer project might be fine, but 95%+ might be quite achievable for the business rules layer, if not wholly necessary. So the overall coverage may be, say, 60%, but the critical business logic may be much higher.
I've also heard this: aspire to 100% and you'll hit 80%; but aspire to 80% and you'll hit 40%.
Bottom line: Apply the 80:20 rule, and let your app's bug count guide you.
85% would be a good starting place for checkin criteria.
I'd probably chose a variety of higher bars for shipping criteria - depending on the criticality of the subsystems/components being tested.
I use cobertura, and whatever the percentage, I would recommend keeping the values in the cobertura-check task up-to-date. At the minimum, keep raising totallinerate and totalbranchrate to just below your current coverage, but never lower those values. Also tie in the Ant build failure property to this task. If the build fails because of lack of coverage, you know someone's added code but hasn't tested it. Example:
<cobertura-check linerate="0"
branchrate="0"
totallinerate="70"
totalbranchrate="90"
failureproperty="build.failed" />
When I think my code isn't unit tested enough, and I'm not sure what to test next, I use coverage to help me decide what to test next.
If I increase coverage in a unit test - I know this unit test worth something.
This goes for code that is not covered, 50% covered or 97% covered.
Code coverage is just another metric. In and of itself, it can be very misleading (see www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated). Your goal should therefore not be to achieve 100% code coverage but rather to ensure that you test all relevant scenarios of your application.
I prefer to do BDD, which uses a combination of automated acceptance tests, possibly other integration tests, and unit tests. The question for me is what the target coverage of the automated test suite as a whole should be.
That aside, the answer depends on your methodology, language and testing and coverage tools. When doing TDD in Ruby or Python it's not hard to maintain 100% coverage, and it's well worth doing so. It's much easier to manage 100% coverage than 90-something percent coverage. That is, it's much easier to fill coverage gaps as they appear (and when doing TDD well coverage gaps are rare and usually worth your time) than it is to manage a list of coverage gaps that you haven't gotten around to and miss coverage regressions due to your constant background of uncovered code.
The answer also depends on the history of your project. I've only found the above to be practical in projects managed that way from the start. I've greatly improved the coverage of large legacy projects, and it's been worth doing so, but I've never found it practical to go back and fill every coverage gap, because old untested code is not well understood enough to do so correctly and quickly.
If you've been doing unit testing for a decent amount of time, I see no reason for it not to be approaching 95%+. However, at a minimum, I've always worked with 80%, even when new to testing.
This number should only include code written in the project (excludes frameworks, plugins, etc.) and maybe even exclude certain classes composed entirely of code written of calls to outside code. This sort of call should be mocked/stubbed.
Generally speaking, from the several engineering excellence best practices papers that I have read, 80% for new code in unit tests is the point that yields the best return. Going above that CC% yields a lower amount of defects for the amount of effort exerted. This is a best practice that is used by many major corporations.
Unfortunately, most of these results are internal to companies, so there are no public literatures that I can point you to.
Code coverage is great but only as long as the benefits that you get from it outweigh the cost/effort of achieving it.
We have been working to a standard of 80% for some time, however we have just made the decison to abandon this and instead be more focused on our testing. Concentrating on the complex business logic etc,
This decision was taken due to the increasing amount of time we spent chasing code coverage and maintaining existing unit tests. We felt we had got to the point where the benefit we were getting from our code coverage was deemed to be less than the effort that we had to put in to achieve it.
Check out Crap4j. It's a slightly more sophisticated approach than straight code coverage. It combines code coverage measurements with complexity measurements, and then shows you what complex code isn't currently tested.
My answer to this conundrum is to have 100% line coverage of the code you can test and 0% line coverage of the code you can't test.
My current practice in Python is to divide my .py modules into two folders: app1/ and app2/ and when running unit tests calculate the coverage of those two folders and visually check (I must automate this someday) that app1 has 100% coverage and app2 has 0% coverage.
When/if I find that these numbers differ from standard I investigage and alter the design of the code so that coverage conforms to the standard.
This does mean that I can recommend achieving 100% line coverage of library code.
I also occasionally review app2/ to see if I could possible test any code there, and If I can I move it into app1/
Now I'm not too worried about the aggregate coverage because that can vary wildly depending on the size of the project, but generally I've seen 70% to over 90%.
With python, I should be able to devise a smoke test which could automatically run my app while measuring coverage and hopefully gain an aggreagate of 100% when combining the smoke test with unittest figures.
Viewing coverage from another perspective: Well-written code with a clear flow of control is the easiest to cover, the easiest to read, and usually the least buggy code. By writing code with clearness and coverability in mind, and by writing the unit tests in parallel with the code, you get the best results IMHO.
In my opinion, the answer is "It depends on how much time you have". I try to achieve 100% but I don't make a fuss if I don't get it with the time I have.
When I write unit tests, I wear a different hat compared to the hat I wear when developing production code. I think about what the tested code claims to do and what are the situations that can possible break it.
I usually follow the following criteria or rules:
That the Unit Test should be a form of documentation on what's the expected behavior of my codes, ie. the expected output given a certain input and the exceptions it may throw that clients may want to catch (What the users of my code should know?)
That the Unit Test should help me discover the what if conditions that I may not yet have thought of. (How to make my code stable and robust?)
If these two rules doesn't produce 100% coverage then so be it. But once, I have the time, I analyze the uncovered blocks and lines and determine if there are still test cases without unit tests or if the code needs to be refactored to eliminate the unecessary codes.
It depends greatly on your application. For example, some applications consist mostly of GUI code that cannot be unit tested.
I don't think there can be such a B/W rule.
Code should be reviewed, with particular attention to the critical details.
However, if it hasn't been tested, it has a bug!
Short answer: 60-80%
Long answer: I think it totally depends on the nature of your project. I typically start a project by unit testing every practical piece. By the first "release" of the project you should have a pretty good base percentage based on the type of programming you are doing. At that point you can start "enforcing" a minimum code coverage.
Depending on the criticality of the code, anywhere from 75%-85% is a good rule of thumb. Shipping code should definitely be tested more thoroughly than in house utilities, etc.
This has to be dependent on what phase of your application development lifecycle you are in.
If you've been at development for a while and have a lot of implemented code already and are just now realizing that you need to think about code coverage then you have to check your current coverage (if it exists) and then use that baseline to set milestones each sprint (or an average rise over a period of sprints), which means taking on code debt while continuing to deliver end user value (at least in my experience the end user doesn't care one bit if you've increased test coverage if they don't see new features).
Depending on your domain it's not unreasonable to shoot for 95%, but I'd have to say on average your going to be looking at an average case of 85% to 90%.
I think the best symptom of correct code coverage is that amount of concrete problems unit tests help to fix is reasonably corresponds to size of unit tests code you created.
I think that what may matter most is knowing what the coverage trend is over time and understanding the reasons for changes in the trend. Whether you view the changes in the trend as good or bad will depend upon your analysis of the reason.
We were targeting >80% till few days back, But after we used a lot of Generated code, We do not care for %age, but rather make reviewer take a call on the coverage required.
From the Testivus posting I think the answer context should be the second programmer. Having said this from a practical point of view we need parameter / goals to strive for. I consider that this can be "tested" in an Agile process by analyzing the code we have the architecture, functionality (user stories), and then come up with a number. Based on my experience in the Telecom area I would say that 60% is a good value to check.
참고URL : https://stackoverflow.com/questions/90002/what-is-a-reasonable-code-coverage-for-unit-tests-and-why
'developer tip' 카테고리의 다른 글
| ConcurrentHashMap과 Collections.synchronizedMap (Map)의 차이점은 무엇입니까? (0) | 2020.10.03 |
|---|---|
| 작업중인 현재 셸을 확인하는 방법은 무엇입니까? (0) | 2020.10.03 |
| 멀티 코어 머신의 Node.js (0) | 2020.10.03 |
| UTF8 인코딩을 사용하여 Excel에서 CSV로 (0) | 2020.10.03 |
| 정규식에서 특정 단어를 부정하는 방법은 무엇입니까? (0) | 2020.10.03 |