단위 테스트가 그렇게 훌륭하다면 왜 더 많은 회사에서 수행하지 않습니까? [닫은]
제가 일한 최초의 실제 소프트웨어 회사는 단위 테스트 (NUnit)에 관한 것입니다. 그 당시에는 우리가 정말 고집 스러웠는지 모르겠습니다. 코드 커버리지가 어떤 것인지 전혀 몰랐고 대부분의 단위 테스트를 작성했습니다. 그 이후로 많은 테스트를 수행하는 일부 회사를 만났습니다. 그러나 그것은 의자 테스트입니다. 사람에 의존하고 반복성이 낮고 버그를 잡을 가능성이 낮습니다. 다른 태도는 다음과 같습니다. "미래에"함께 진행하고 싶었던 것입니다. 기본적으로 돈이 하늘에서 떨어질 때.
단위 테스트가 그리워요. 하지만 새로운 직업을 찾을 때 단위 테스트는 회사가 미래에 "계속 진행"하기를 원하거나 전혀하지 않는 것입니다 (어, 그것은 한동안 존재했습니다 지금!). 지난 2 년 동안 내가 살펴본 작업 요구 사항의 60-75 %가 단위 테스트를 전혀 나열하지 않았다고 말하고 싶습니다. 단위 테스트 경험이있는 한두 명만 (중급 개발자 위치) 요구 사항으로 생각할 수 있습니다.
그래서 질문은, 무엇이 빠졌 습니까? 사람들을 더 생산적으로 만든다고 생각하지만, 실제로 그렇게하는 데 상당한 시간을 보낸 후에야합니다. 단위 테스트의 비용 절감에 대한 좋은 연구가 없습니까? 내가보고있는 회사 유형입니까?
편집 : 제목이 약간 악마 옹호자이지만 나는 자신을 단위 테스트 지지자라고 생각합니다.
내 경험상 여기에는 몇 가지 요소가 관련되어 있습니다.
- 경영진은 단위 테스트가 실제로 무엇인지, 왜 그것이 실제 내재적 가치를 가지고 있는지 이해하지 못합니다.
- 경영진은 빠른 제품 제공에 더 관심을 갖는 경향이 있으며 단위 테스트가 해당 목표에 역효과를주는 것으로 (잘못) 인식합니다.
- 테스트가 전적으로 QA의 관점에 속한다는 오해가 있습니다. 개발자는 코더이며 테스트를 작성할 수 없습니다.
- 도구를 무료로 사용할 수 있다는 사실에도 불구하고 경영진이 단위 테스트를 올바르게 수행하기 위해 돈을 써야한다는 일반적인 오해가 있습니다. (물론 개발자가 고려할 시간을 늘리는 것이 있지만 실제로 금지되지는 않습니다.)
- Will의 대답은이 대답을 반올림합니다. 테스트 코드의 가치를 결정하는 것은 매우 어렵습니다 (jcollum 편집).
당연히 다른 요소가 있지만 지금까지 내가 겪은 것입니다.
1) 어렵다
2) 시간이 걸린다
3) 테스트 코드의 가치를 결정하는 것이 매우 어렵다
포인트 3은 끈적 거리는 것입니다. 좋은 단위 테스트는 버그를 줄입니다. 그러나 좋은 프로덕션 코드도 마찬가지입니다. 단위 테스트로 인해 존재하지 않는 버그 수를 어떻게 결정합니까? 존재하지 않는 것을 측정 할 수 없습니다. 연구를 가리킬 수는 있지만 비즈니스 관리자의 스프레드 시트에는 적합하지 않습니다.
모든 책임을 "관리"에 두는 것은 쉽습니다. 그러나 경영진이 정말로 단위 테스트를하지 말라고 말하고 있습니까?
일반적으로 관리는 모듈화, 추상 데이터 유형, 디자인 패턴 또는 단위 테스트에 관계없이 작업을 수행하는 방법을 알려주지 않습니다. 이들은 성공적이고 유능한 소프트웨어 엔지니어가 적용하는 거래 도구이지만 열악한 엔지니어는 적용하지 않습니다.
귀하의 질문에 대한 진정한 대답은 다음과 같습니다. 단위 테스트는 정말 어렵고 컴퓨터 과학 학생들은 이에 대한 훈련을받지 않았습니다.
자신 만의 문자열 클래스를 작성할 때 쉽습니다. 실제 제품을 테스트 할 때 파워 포인트 슬라이드에서 아무도 말하지 않은 문제에 직면하게됩니다.
- 사용자 상호 작용. 애플리케이션의 절반은 사용자 인터페이스 로직입니다. 버튼을 움직여도 분해되지 않는 자동화 된 방식으로 어떻게 테스트합니까?
- 외부 API 및 프레임 워크와의 상호 작용. Windows 커널 드라이버를 작성하는 경우 어떻게 단위 테스트합니까? 사용하는 모든 IRP 및 커널 기능에 대한 스텁을 작성하여 효과적으로 OS 커널 시뮬레이션을 생성합니까?
- 네트워크 통신은 21 세기의 것입니다. 여러 분산 구성 요소로 구성된 단위 테스트를 어떻게 조정합니까?
- 좋은 테스트 케이스를 어떻게 선택합니까? 나는 일반적으로 사람들이 "1000 번의 반복 루프에서 임의의 작업을 수행하고 중단되는지 확인"접근 방식을 시도하는 것을 봅니다. 이렇게하면 노력이 수익보다 높고 중요한 버그가 누락되고 단위 테스트가 중단됩니다.
- 성능 요구 사항이 충족되는지 어떻게 테스트합니까?
- 테스트의 패턴에 대한 지식은 거의 없습니다. 스텁, 미리 준비된 답변, 회귀 테스트는 대부분의 사람들이 모르는 개념입니다. 직장에서 실제로 단위 테스트에 대한 책을 읽은 사람은 몇 명입니까?
우리가 관리를 비난 할 수있는 한 가지는 요구 사항 사양에 결과물의 품질 수준에 대한 요구 사항이 거의 포함되지 않는다는 것입니다.
다음에 상사가 예상 시간을 요구할 때 단위 테스트 작성 시간을 포함하고 어떤 일이 발생하는지 확인하십시오.
대부분의 테스트는 아무것도 테스트하지 않습니다.
fileopen () 함수와 파일이 존재하지 않으면 실패하고 파일이 존재하면 성공하는 unittest를 작성합니다. 큰! 이제 BIG5 중국어의 파일 이름으로 작동하는지 확인 했습니까? NFS 공유에 있습니까? USB 키에있는 파일과 UAC가 켜져있는 Vista에서
문제는 함수를 작성한 동일한 프로그래머가 동일한 수준의 기술로 동일한 가정에 따라 단위 테스트를 작성한다는 것입니다. 실제로 작동하려면 다른 사람이 테스트를 작성해야하며 코드를 보지 않고 게시 된 사양에 대해서만 작성해야합니다. -대부분의 회사에서 사양을 작성하는 것만으로도 돌파구가 될 것입니다!
단위 테스트는 개별 함수 코드의 오류를 확인합니다. 입력 / 출력이 잘 알려져 있고 내부 구조가 복잡하지만 많은 경우 시간 낭비 일 뿐인 데이터 액세스 레이어, 수학 라이브러리 등에서 작동 할 수 있습니다.
오류가 코드의 다른 부분 또는 OS 및 사용자와의 상호 작용으로 인한 경우 실패합니다. 높은 / 낮은 DPI 설정이 대화 상자를 엉망으로 만들거나 '.'을 바꾸는 외국어 설정과 같은 문제 및 ','는 일반적으로 발견되지 않습니다.
단위 테스트의 ROI에 대한 연구가 수행되었습니다 . 이 질문을 참조하십시오 .
단위 테스트에 관심이없는 개발자를 많이 찾았습니다. 당신이 시작할 때 그것은 항상 적은 보수로 많은 일처럼 보입니다. 아무도 추가 작업에 등록하고 싶어하지 않으므로 저항합니다. 일단 사람들이 시작하면 보통 열정적으로 고수하지만 시작하는 것은 어려울 수 있습니다.
단위 테스트의 채택 문제를 제외하고는 단위 테스트가 항상 가치가있는 것은 아니지만 일반적으로 적절하게 적용될 때 그렇다고 생각합니다. 단위 테스트가 열악한 구성에 취약하지 않도록 보호하는 특별한 것은 없습니다.
단위 테스트에는 비용 (생성, 유지 관리 및 실행)이 있으며 해당 비용보다 더 큰 이점을 제공하는 경우에만 가치가 있습니다. 테스트 생성은 다른 기술과 마찬가지로 성공을 위해 특정 경험과 지식이 필요합니다. 충분한 경험이 없으면 다른 경험이있는 개발자라도 가치가없는 낮은 품질, 낮은 가치 및 / 또는 높은 비용의 단위 테스트를 만드는 것은 매우 쉽습니다. 특히 단위 테스트의 가치를 판단하는 것이 얼마나 어려운지를 감안할 때.
또한 단위 테스트는 코드 품질을 향상시키는 한 가지 방법 일뿐 아니라 유일한 방법은 아닙니다. 어떤 상황에서는 어떤 팀에서는 소프트웨어 품질을 높이는 가장 효과적인 방법이 아닐 수 있습니다.
단위 테스트에 많은 노력을 기울이는 것이 소프트웨어 품질을 보장하는 것은 아닙니다. 또한 단위 테스트 없이도 최고 품질의 소프트웨어를 생산할 수 있습니다.
글쎄, 우리 회사는 TDD 또는 단위 테스트를 사용하지 않았습니다. 솔직히 우리는 어떻게해야할지 모르겠습니다. 우리는 CapitalizeString () 등과 같은 어리석은 함수에 대해 분명히 할 수 있지만 복잡한 객체가있는 매우 복잡한 시스템에 대해 수행하는 방법을 모릅니다. 또한 인터뷰에 응한 대부분의 사람들은 경험이 없거나 제한적이었습니다. 단위 테스트는 SO 군중에서 큰 것으로 보이지만 사용 가능한 작업 풀에서는 특별히 크지 않습니다.
TDD is a separate topic. We are morally opposed to TDD. We aren't cowboy coders, but we do believe that it stunts creativity and flexibility in a project. Moreover, having the coder who wrote the unit testing function makes no sense. When I do something, I code to all of the edge cases I can think of. What I need is another brain to look for things I might have missed. We don't have that. The teams are small and self-contained.
In short, we don't believe in TDD, but we would like to Unit Test. We just don't have the experience to do so, and we can't find it easily.
There are plenty of companies out there that really do nothing along the lines of best practices. No code reviews, no unit testing, no testing plans, no nothing, just by the seat of their pants.
Take this as an opportunity to get them to use a Continuous Integration platform and develop unit tests! Easy way to impress the powers that be and increase the quality and stability of your code at the same time
Edit: As for reason, I think they just plain aren't aware of the current tools out there that make CI and unit testing extraordinarily easy.
Unit testing should be just a natural part of the code development workflow, just as the compiler is.
However, this requires educating the management on the benefits of the unit testing. Junior developers have relatively low chances to have such influence, though. Thus, whether a company is a proponent of the unit testing depends on whether they have a senior developer or architect that is an advocate of unit testing.
I believe this is the answer to your question "what's missing and why aren't more companies doing unit testing". :-)
Its probably a combination of a couple of things you mentioned already. Its difficult to measure cost savings of TDD. If you want to outsource your IT, you can show how much you pay per year for the guys you have on staff vs. the cost of contracting it out; its very concrete. How do you say, "Oh, this test caught a bug which would have taken me 4 hours to debug and fix..."?
The reason some places don't use it is simply because it takes a lot of work both to get started and to continue. The fact that writing unit tests takes about as much time as writing the actual functionality seems to some managers like you're cutting your developer's productivity in half.
On top of that, you build team (or someone) needs to put the infrastructure in place and maintain it.
And as Alan says, a lot of places simply don't use best practices - they just want to see something tangible.
I don't think laziness is the root cause of bad unit testing. For my company, time constraints and "just get it done" attitude are the biggest deterrents for doing unit testing. Also, the places where our systems fail tend to be more at the integration level (services, database accesses, complex queries that require specific data for testing), not the "unit level." These things are just harder to test, and if you barely have enough time to get the feature done, you're probably not going to have time to get any useful tests done at the same time.
I think that the programmer has to just start doing it. A few simple tests to start with are easy to justify as part of development.
Something like a unit test is almost always necessary to get fast debugging turn around. Just explain how much faster it is to launch the test than it is to arrange the correct input, set a debugger breakpoint, launch the application, etc.
Document the test in your code. Just put a comment explaining where the test is and how to run it. Future programmers will see it and hopefully the testing will spread!
From what I've seen, a lot of companies have huge, highly-coupled code bases that aren't practically unit testable. They also don't have decent testable requirements, so the unit tests would test against "as built" de facto requirements.
Unit testing is one of those black box terms that most people have heard, but don't know what exactly constitutes a unit test, where to start, how to write them, how to actually run tests, what exactly they should be testing, etc. etc. etc.
In a lot of cases, its easier for the unsure developer to simply dismiss them as unnecessary or some icing that only "enterprise level developers" need.
I'm a huge fan of unit tests and I also am a partner in a company doing contract development projects for various client types. In a month we'll touch 3-4 different projects of varying sizes.
If a project seems like it's going to be a one off, I'm not going to invest heavily in unit testing because that unit testing doesn't pay off for my business. On those types of projects I'm going to unit test things that I'm uncertain/unfamiliar with or that could change frequently (such as a parser for a data source I don't control.)
Whereas if I'm building something that I know is going to have a long life time, is a larger piece of work, that I'll be working with through multiple iterations, or will have a large impact on my clients if an error occurs, I'm going to invest in more unit testing. Again priority of tests revolves around uncertain/unfamiliar/changing code.
I think unit tests ought to revolve around the complexity of a task, as well as whether they're going to pay off. There's no sense in writing extra code that isn't going to get used.
In my experience it really depends on the software you are writing. I have found it is extremely hard to write unit tests for a UI. I only use unit tests for portions of the system that have a definite in/out.
I miss unit testing -- it just makes life easier.
That is not, really, a sufficient reason for a company to adopt unit testing.
A sufficient reason might be "cheaper" (and/or, "better"): which is not as easy to prove about unit testing.
The only good reason might be "writing unit tests is the best use of developers' time", which is really hard to prove IMO: and it may be true in some places, for some software, with some developers, and not true elsewhere.
There are plenty of developers who don't think the world of unit tests: including some who think that other forms of testing (e.g. automated integration/functional tests) may be cheaper and more valuable, for example Am I the only dev who doesn't like unit tests?
Of course, in the ideal world, you can not argue against having a unit test.
However, whether you write a unit test depends on a number of things:
How the software will be used. If you were writing software for just yourself would you write unit tests? Probably not. If you were writing pre-packaged software to be sold commercially, probably yes.
How many people maintain the code....if it's just you, then you may know it well enough to be confident enough after making a change that a quick run through of the code is sufficient to ensure nothing has broken. If other people who did not originally write the code must now maintain it then a unit test will help give them confidence that when they update the code to fix a big (that was obviously not captured in the unit test!) they have not broken anything.
code complexity: only test code which needs a test. A one line variable assignment method does not need testing. A 50 line method with multiple paths of execution probably does.
Practical commercial commercial considerations: The fact is writing unit tests does take longer than not doing so. If you are writing prototype software, that has an uncertain commercial future, then there is a pay off to be has between having code quickly, now, that works sufficiently well versus having unit tested code in 2 weeks that works better. Sometimes it pays to find out quickly (consumer appetite) if software will have a short shelf like and move on to the next project.
and as others have pointed out, a test is only as good as the person that wrote it.
The main reason is that many developers and development managers don't have a clue that unit tests exist, or how to use them.
The second reason is that unit tests can only be used (in a sensible manner) with code that already fulfills some quality standards. Chances are, that some existing codebase doesn't fall into that category.
The third reason is lazyness and/or cheapness.
Because unit tests are only usefull if you write testable code. And writing testable code is hard. And people are lazy and / or cheap.
EDIT : nuanced "lazy" as "lazy and / or cheap" ; some rare times, people actually have the skill and capacity and will to write tests, but they have something else to do that more directly affects the bottom line.
I think part of the problem is that developers are expecting business people to have the same set of values and to really care about the answer to "should we unit test or not?". We don't get approval beforehand from the business to use a high-level language rather than assembly language -- it's just usually the sensible way to get the work done.
The point is, we are the only ones qualified to make the call (which isn't to say that all of us have the same knowledge on the topic). Furthermore, even if your team doesn't, as a matter of policy, do unit testing (or name-your-method-of-the-day) it generally doesn't mean that you can't do it.
The truth is, we can't really prove ROI on most of the stuff we do at too fine of a granularity. Why unit testing is held up to this unreasonable/non-typical standard of proof is beyond me...
People are lazy and only adopt change when forced to.
My 2 cents:
- It requires some education and discipline, but new graduates already come with the proper knowledge.
- Tests overhead can be reduced with better tools and this is happening also (refactoring etc.)
So, it's just a matter of time.
There's the Martin-Coplien debate in which Bob Martin asserts that:
"nowadays it is irresponsible for a developer to ship a line of code he has not executed in a unit test."
[http://www.infoq.com/interviews/coplien-martin-tdd]
If you want to sell everyone on testing do the following:
- Write a bunch of tests.
- Notify the other developers who change code and fail your test(s).
- They'll fix their code.
- Now you can release without those particular bugs.
Even a manager could understand this.
Companies are not performing unit testing, for the same reason that many websites are written poorly – ignorance, and people sticking to old habits. At my company, since we started unit testing (with Nunit, and Typemock), we reach higher code coverage and release the software in a shorter time to market.
Like most good ideas, adoption has more to do with organizational path dependence than with the quality of idea.
In most companies that have shipped products, a substantial QA division has been created with a senior level QA head. Testing is the fiefdom of the QA team.
The QA team is unlikely to write unit test code because the company typically doesn't staff the QA team with its heavy duty coders.
The programming team is reluctant to write test code because it creates a conflict with the QA team.
I've been seeing more interest and adoption of Unit Testing in groups where QA hasn't been spun off into a separate job function
Simple it cost money to write and update unit tests. Most of companies previous software doesn't have unit tests and will cost too much to write. So they do not do it and it adds time to the development process so they also do not add it to new features.
Most companies are useless. Not the one that you (or I) work for, obviously.
'IT박스' 카테고리의 다른 글
| 편집기에서 재생할 때 Xcode Simulator 애니메이션이 매우 느림 (0) | 2020.08.14 |
|---|---|
| 앱 시작시 흰색 화면을 수정하는 방법은 무엇입니까? (0) | 2020.08.14 |
| 쉘 변수에서 웹 페이지의 내용을 얻는 방법은 무엇입니까? (0) | 2020.08.13 |
| Nant 0.91에서 구성 오류를 해결하려면 어떻게해야합니까? (0) | 2020.08.13 |
| 스키마를 정의하지 않고 Mongoose를 어떻게 사용합니까? (0) | 2020.08.13 |