단위 테스트 란 무엇입니까?

단위 테스트 란 무엇입니까? [닫은]

---

특정 언어로 단위 테스트를하는 방법을 묻는 많은 질문을 보았지만 '무엇을', '왜', '언제'를 묻는 질문은 없었습니다.

• 무엇입니까?
• 그것은 나를 위해 무엇을합니까?
• 왜 사용해야합니까?
• 언제 사용해야합니까?
• 일반적인 함정과 오해는 무엇입니까

---

단위 테스트는 대략 코드 코드를 테스트 코드와 별도로 테스트하는 것입니다. 떠오르는 장점은 다음과 같습니다.

• 테스트 실행이 자동화되고 반복 가능 해짐
• GUI를 통한 포인트 앤 클릭 테스트보다 훨씬 세밀한 수준으로 테스트 할 수 있습니다.

테스트 코드가 파일에 쓰거나 데이터베이스 연결을 열거 나 네트워크를 통해 무언가를 수행하는 경우 통합 테스트로 더 적절하게 분류됩니다. 통합 테스트는 좋지만 단위 테스트와 혼동해서는 안됩니다. 단위 테스트 코드는 짧고 달콤하며 실행이 빠릅니다.

단위 테스트를 보는 다른 방법은 먼저 테스트를 작성하는 것입니다. 이것을 TDD (Test-Driven Development)라고합니다. TDD는 다음과 같은 장점이 있습니다.

• 당신은 투기적인 "나중에 이것을 필요로 할지도 모른다"라는 코드를 작성하지 않습니다.
• 당신이 작성한 코드는 항상 테스트에 의해 커버됩니다
• 테스트를 먼저 작성하면 코드를 호출하는 방법에 대해 생각해야하는데 이는 일반적으로 장기적으로 코드 디자인을 향상시킵니다.

지금 단위 테스트를 수행하지 않는 경우 시작하는 것이 좋습니다. 좋은 책을 얻으십시오. 실질적으로 모든 xUnit-book에서 할 수있는 개념은 그들 사이에 개념이 많이 전달되기 때문입니다.

때때로 단위 테스트를 작성하는 것이 어려울 수 있습니다. 그렇게되면, 당신을 도울 사람을 찾고, "그냥 코드를 작성하라"는 유혹에 저항하십시오. 단위 테스트는 설거지와 비슷합니다. 항상 즐겁지는 않지만 은유 적 인 주방을 깨끗하게 유지하고 실제로 깨끗하게 만들고 싶습니다. :)

---

편집 : 하나의 오해가 떠 오릅니다.하지만 그것이 일반적인지 확실하지 않습니다. 프로젝트 관리자가 단위 테스트로 인해 팀이 모든 코드를 두 번 작성했다고 말합니다. 그것이 그렇게 보이고 느껴지면, 잘못하고있는 것입니다. 테스트를 작성하면 일반적으로 개발 속도가 빨라질뿐만 아니라 그렇지 않은 편리한 "지금 완료되었습니다"표시를 제공합니다.

---

나는 Dan과 동의하지 않습니다 (더 나은 선택은 대답하지 않을 수도 있지만) ...

단위 테스트는 시스템의 동작 및 기능을 테스트하기위한 코드 작성 프로세스입니다.

분명히 테스트는 코드의 품질을 향상 시키지만 단위 테스트의 피상적 인 이점 일뿐입니다. 실제 이점은 다음과 같습니다.

1. 동작 (리팩토링)을 변경하지 않으면 서 기술 구현을보다 쉽게 ​​변경할 수 있습니다. 제대로 테스트 된 코드는 눈에 띄지 않고 아무것도 깨뜨리지 않고 공격적으로 리팩토링 / 정리할 수 있습니다.
2. 동작을 추가하거나 수정할 때 개발자에게 확신을 제공하십시오.
3. 코드를 문서화하십시오
4. 밀접하게 결합 된 코드 영역을 나타냅니다. 밀접하게 연결된 코드를 단위 테스트하기가 어렵습니다.
5. API를 사용하고 초기에 어려움을 찾을 수있는 수단 제공
6. 응집력이 좋지 않은 메소드와 클래스를 나타냅니다.

유지 보수 가능하고 우수한 품질의 제품을 고객에게 제공하려면 관심사가 있기 때문에 단위 테스트를 수행해야합니다.

실제 동작을 모델링하는 시스템 또는 시스템의 일부에 사용하는 것이 좋습니다. 즉, 엔터프라이즈 개발에 특히 적합합니다. 버리기 / 유틸리티 프로그램에는 사용하지 않겠습니다. 테스트하기 어려운 시스템의 일부에는 사용하지 않을 것입니다 (UI는 일반적인 예이지만 항상 그런 것은 아닙니다)

가장 큰 함정은 개발자가 너무 큰 단위를 테스트하거나 메소드를 단위로 간주한다는 것입니다. 제어 역전 (Inversion of Control)을 이해하지 못하는 경우 특히 그렇습니다.이 경우 단위 테스트는 항상 종단 간 통합 테스트로 바뀝니다. 단위 테스트는 개별 동작을 테스트해야하며 대부분의 방법에는 많은 동작이 있습니다.

가장 큰 오해는 프로그래머가 테스트해서는 안된다는 것입니다. 나쁘거나 게으른 프로그래머 만이 그것을 믿습니다. 지붕을 짓는 사람이 테스트하지 않습니까? 심장 판막을 교체하는 의사가 새 판막을 검사하지 않아야합니까? 프로그래머 만이 자신의 코드가 의도 한대로 작동하는지 테스트 할 수 있습니다 (QA는 프로그래머가 의도하지 않은 일을하도록 지시를 받았을 때 코드가 동작하는 방식과 클라이언트가 수락 테스트를 수행 할 수있는 방식을 테스트 할 수 있음) 고객이 지불 한 금액

---

"새로운 프로젝트를 열고이 특정 코드를 테스트하는 것"과 반대로 단위 테스트의 주요 차이점은 자동화 되어 반복 가능 하다는 것 입니다.

코드를 수동으로 테스트하면 코드가 현재 상태에서 완벽하게 작동하고 있음을 확신 할 수 있습니다 . 그러나 일주일 후에 약간 수정하면 어떨까요? 당신은 할 때마다 손으로 다시 재시험 기꺼이 아무것도 코드의 변화? 아마 아닐 것 :-(

당신이 수 있다면 몇 초 내에 한 번의 클릭으로, 동일한 방식으로, 당신의 검사 결과 언제든지 실행 , 그들은 것입니다 문제가 생겼 때마다 즉시을 보여줍니다. 또한 단위 테스트를 자동화 된 빌드 프로세스에 통합하는 경우 완전히 관련이없는 것처럼 보이는 변경이 코드베이스의 먼 부분에 문제가 발생한 경우에도 버그를 경고합니다. 특정 기능을 다시 테스트해야합니다.

이것이 수동 테스트보다 단위 테스트의 주요 이점입니다. 그러나 더 많은 것이 있습니다.

• 단위 테스트 는 개발 피드백 루프를 획기적으로 단축시킵니다 . 별도의 테스트 부서를 사용하면 코드에 버그가 있음을 알기까지 몇 주가 소요될 수 있습니다. 이미 많은 컨텍스트를 잊어 버렸기 때문에 몇 시간이 걸릴 수 있습니다. 버그를 찾아 수정하십시오. 단위 테스트를 통한 OTOH, 피드백주기는 초 단위로 측정되며, 버그 수정 프로세스는 일반적으로 "오 sh * t, 그 상태를 확인하는 것을 잊었습니다":-)
• 단위 테스트 는 코드의 행동을 효과적으로 문서화 합니다
• 단위 테스트를 통해 설계 선택을 재평가해야 하므로 더 단순하고 깔끔한 설계

단위 테스트 프레임 워크를 사용하면 테스트를 쉽게 작성하고 실행할 수 있습니다.

---

나는 대학에서 단위 테스트를 배운 적이 없었고 그것을 "얻는"데는 시간이 걸렸다. 나는 그것에 대해 읽고, "아, 맞아, 자동 테스트, 그것은 멋지다"고 생각하고 잊어 버렸습니다.

내가 요점을 실제로 파악하기까지는 시간이 조금 더 걸렸다. 큰 시스템에서 작업 중이고 작은 모듈을 작성한다고 가정 해 봅시다. 그것은 컴파일하고, 당신은 그것의 페이스를 통과시키고, 훌륭하게 작동하며, 다음 작업으로 넘어갑니다. 9 개월 동안 줄을 잃고 두 버전이 지나면 다른 사람이 프로그램의 관련이없는 것으로 변경되어 모듈이 손상됩니다. 더 나쁜 것은 변경 사항을 테스트하고 코드가 작동하지만 모듈을 테스트하지는 않는다는 것입니다. 지옥, 그들은 당신의 모듈 이 존재한다는 것을 알지 못할 수도 있습니다 .

그리고 이제 문제가 생겼습니다. 깨진 코드가 트렁크에 있고 아무도 몰랐습니다. 가장 좋은 경우는 내부 테스터가 배송 전에 발견하지만 게임 후반에 코드를 수정하는 것은 비용이 많이 든다는 것입니다. 그리고 내부 테스터가 그것을 찾지 못하면 ... 매우 비싸 질 수 있습니다.

해결책은 단위 테스트입니다. 코드를 작성할 때 문제가 생길 수 있지만, 이는 직접 수행 할 수 있습니다. 실제로는 완전히 다른 프로젝트를 진행할 때 9 개월 동안 문제가 발생하지만 여름 인턴은 해당 매개 변수가 알파벳 순서로 정렬되면 더 깔끔해 보일 것이라고 생각합니다. 당신은 되돌아가는 길을 썼고 누군가가 매개 변수 순서를 다시 바꿀 때까지 인턴에 물건을 던졌습니다. 이것이 단위 테스트의 "이유"입니다. :-)

---

Chipping in on the philosophical pros of unit testing and TDD here are a few of they key "lightbulb" observations which struck me on my tentative first steps on the road to TDD enlightenment (none original or necessarily news)...

1. TDD does NOT mean writing twice the amount of code. Test code is typically fairly quick and painless to write and is a key part of your design process and critically.

2. TDD helps you to realize when to stop coding! Your tests give you confidence that you've done enough for now and can stop tweaking and move on to the next thing.

3. The tests and the code work together to achieve better code. Your code could be bad / buggy. Your TEST could be bad / buggy. In TDD you are banking on the chances of BOTH being bad / buggy being fairly low. Often its the test that needs fixing but that's still a good outcome.

4. TDD helps with coding constipation. You know that feeling that you have so much to do you barely know where to start? It's Friday afternoon, if you just procrastinate for a couple more hours... TDD allows you to flesh out very quickly what you think you need to do, and gets your coding moving quickly. Also, like lab rats, I think we all respond to that big green light and work harder to see it again!

5. In a similar vein, these designer types can SEE what they're working on. They can wander off for a juice / cigarette / iphone break and return to a monitor that immediately gives them a visual cue as to where they got to. TDD gives us something similar. It's easier to see where we got to when life intervenes...

6. I think it was Fowler who said: "Imperfect tests, run frequently, are much better than perfect tests that are never written at all". I interprete this as giving me permission to write tests where I think they'll be most useful even if the rest of my code coverage is woefully incomplete.

7. TDD helps in all kinds of surprising ways down the line. Good unit tests can help document what something is supposed to do, they can help you migrate code from one project to another and give you an unwarranted feeling of superiority over your non-testing colleagues :)

This presentation is an excellent introduction to all the yummy goodness testing entails.

---

I would like to recommend the xUnit Testing Patterns book by Gerard Meszaros. It's large but is a great resource on unit testing. Here is a link to his web site where he discusses the basics of unit testing. http://xunitpatterns.com/XUnitBasics.html

---

I use unit tests to save time.

When building business logic (or data access) testing functionality can often involve typing stuff into a lot of screens that may or may not be finished yet. Automating these tests saves time.

For me unit tests are a kind of modularised test harness. There is usually at least one test per public function. I write additional tests to cover various behaviours.

All the special cases that you thought of when developing the code can be recorded in the code in the unit tests. The unit tests also become a source of examples on how to use the code.

It is a lot faster for me to discover that my new code breaks something in my unit tests then to check in the code and have some front-end developer find a problem.

For data access testing I try to write tests that either have no change or clean up after themselves.

Unit tests aren’t going to be able to solve all the testing requirements. They will be able to save development time and test core parts of the application.

---

This is my take on it. I would say unit testing is the practice of writing software tests to verify that your real software does what it is meant to. This started with jUnit in the Java world and has become a best practice in PHP as well with SimpleTest and phpUnit. It's a core practice of Extreme Programming and helps you to be sure that your software still works as intended after editing. If you have sufficient test coverage, you can do major refactoring, bug fixing or add features rapidly with much less fear of introducing other problems.

It's most effective when all unit tests can be run automatically.

Unit testing is generally associated with OO development. The basic idea is to create a script which sets up the environment for your code and then exercises it; you write assertions, specify the intended output that you should receive and then execute your test script using a framework such as those mentioned above.

The framework will run all the tests against your code and then report back success or failure of each test. phpUnit is run from the Linux command line by default, though there are HTTP interfaces available for it. SimpleTest is web-based by nature and is much easier to get up and running, IMO. In combination with xDebug, phpUnit can give you automated statistics for code coverage which some people find very useful.

Some teams write hooks from their subversion repository so that unit tests are run automatically whenever you commit changes.

It's good practice to keep your unit tests in the same repository as your application.

---

LibrarIES like NUnit, xUnit or JUnit are just mandatory if you want to develop your projects using the TDD approach popularized by Kent Beck:

You can read Introduction to Test Driven Development (TDD) or Kent Beck's book Test Driven Development: By Example.

Then, if you want to be sure your tests cover a "good" part of your code, you can use software like NCover, JCover, PartCover or whatever. They'll tell you the coverage percentage of your code. Depending on how much you're adept at TDD, you'll know if you've practiced it well enough :)

---

Unit-testing is the testing of a unit of code (e.g. a single function) without the need for the infrastructure that that unit of code relies on. i.e. test it in isolation.

If, for example, the function that you're testing connects to a database and does an update, in a unit test you might not want to do that update. You would if it were an integration test but in this case it's not.

So a unit test would exercise the functionality enclosed in the "function" you're testing without side effects of the database update.

Say your function retrieved some numbers from a database and then performed a standard deviation calculation. What are you trying to test here? That the standard deviation is calculated correctly or that the data is returned from the database?

In a unit test you just want to test that the standard deviation is calculated correctly. In an integration test you want to test the standard deviation calculation and the database retrieval.

---

Unit testing is about writing code that tests your application code.

The Unit part of the name is about the intention to test small units of code (one method for example) at a time.

xUnit is there to help with this testing - they are frameworks that assist with this. Part of that is automated test runners that tell you what test fail and which ones pass.

They also have facilities to setup common code that you need in each test before hand and tear it down when all tests have finished.

You can have a test to check that an expected exception has been thrown, without having to write the whole try catch block yourself.

---

I think the point that you don't understand is that unit testing frameworks like NUnit (and the like) will help you in automating small to medium-sized tests. Usually you can run the tests in a GUI (that's the case with NUnit, for instance) by simply clicking a button and then - hopefully - see the progress bar stay green. If it turns red, the framework shows you which test failed and what exactly went wrong. In a normal unit test, you often use assertions, e.g. Assert.AreEqual(expectedValue, actualValue, "some description") - so if the two values are unequal you will see an error saying "some description: expected <expectedValue> but was <actualValue>".

So as a conclusion unit testing will make testing faster and a lot more comfortable for developers. You can run all the unit tests before committing new code so that you don't break the build process of other developers on the same project.

---

Use Testivus. All you need to know is right there :)

---

Unit testing is a practice to make sure that the function or module which you are going to implement is going to behave as expected (requirements) and also to make sure how it behaves in scenarios like boundary conditions, and invalid input.

xUnit, NUnit, mbUnit, etc. are tools which help you in writing the tests.

---

Test Driven Development has sort of taken over the term Unit Test. As an old timer I will mention the more generic definition of it.

Unit Test also means testing a single component in a larger system. This single component could be a dll, exe, class library, etc. It could even be a single system in a multi-system application. So ultimately Unit Test ends up being the testing of whatever you want to call a single piece of a larger system.

You would then move up to integrated or system testing by testing how all the components work together.

---

First of all, whether speaking about Unit testing or any other kinds of automated testing (Integration, Load, UI testing etc.), the key difference from what you suggest is that it is automated, repeatable and it doesn't require any human resources to be consumed (= nobody has to perform the tests, they usually run at a press of a button).

---

I went to a presentation on unit testing at FoxForward 2007 and was told never to unit test anything that works with data. After all, if you test on live data, the results are unpredictable, and if you don't test on live data, you're not actually testing the code you wrote. Unfortunately, that's most of the coding I do these days. :-)

I did take a shot at TDD recently when I was writing a routine to save and restore settings. First, I verified that I could create the storage object. Then, that it had the method I needed to call. Then, that I could call it. Then, that I could pass it parameters. Then, that I could pass it specific parameters. And so on, until I was finally verifying that it would save the specified setting, allow me to change it, and then restore it, for several different syntaxes.

I didn't get to the end, because I needed-the-routine-now-dammit, but it was a good exercise.

---

What do you do if you are given a pile of crap and seem like you are stuck in a perpetual state of cleanup that you know with the addition of any new feature or code can break the current set because the current software is like a house of cards?

How can we do unit testing then?

You start small. The project I just got into had no unit testing until a few months ago. When coverage was that low, we would simply pick a file that had no coverage and click "add tests".

Right now we're up to over 40%, and we've managed to pick off most of the low-hanging fruit.

(The best part is that even at this low level of coverage, we've already run into many instances of the code doing the wrong thing, and the testing caught it. That's a huge motivator to push people to add more testing.)

---

This answers why you should be doing unit testing.

---

The 3 videos below cover unit testing in javascript but the general principles apply across most languages.

Unit Testing: Minutes Now Will Save Hours Later - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

JS Unit Testing (very good) - https://www.youtube.com/watch?v=-IYqgx8JxlU

Writing Testable JavaScript - https://www.youtube.com/watch?v=OzjogCFO4Zo

---

Now I'm just learning about the subject so I may not be 100% correct and there's more to it than what I'm describing here but my basic understanding of unit testing is that you write some test code (which is kept separate from your main code) that calls a function in your main code with input (arguments) that the function requires and the code then checks if it gets back a valid return value. If it does get back a valid value the unit testing framework that you're using to run the tests shows a green light (all good) if the value is invalid you get a red light and you then can fix the problem straight away before you release the new code to production, without testing you may actually not have caught the error.

So you write tests for you current code and create the code so that it passes the test. Months later you or someone else need to modify the function in your main code, because earlier you had already written test code for that function you now run again and the test may fail because the coder introduced a logic error in the function or return something completely different than what that function is supposed to return. Again without the test in place that error might be hard to track down as it can possibly affect other code as well and will go unnoticed.

---

Also the fact that you have a computer program that runs through your code and tests it instead of you manually doing it in the browser page by page saves time (unit testing for javascript). Let's say that you modify a function that is used by some script on a web page and it works all well and good for its new intended purpose. But, let's also say for arguments sake that there is another function you have somewhere else in your code that depends on that newly modified function for it to operate properly. This dependent function may now stop working because of the changes that you've made to the first function, however without tests in place that are run automatically by your computer you will not notice that there's a problem with that function until it is actually executed and you'll have to manually navigate to a web page that includes the script which executes the dependent function, only then you notice that there's a bug because of the change that you made to the first function.

To reiterate, having tests that are run while developing your application will catch these kinds of problems as you're coding. Not having the tests in place you'd have to manually go through your whole application and even then it can be hard to spot the bug, naively you send it out into production and after a while a kind user sends you a bug report (which won't be as good as your error messages in a testing framework).

---

It's quite confusing when you first hear of the subject and you think to yourself, am I not already testing my code? And the code that you've written is working like it is supposed to already, "why do I need another framework?"... Yes you are already testing your code but a computer is better at doing it. You just have to write good enough tests for a function/unit of code once and the rest is taken care of for you by the mighty cpu instead of you having to manually check that all of your code is still working when you make a change to your code.

Also, you don't have to unit test your code if you don't want to but it pays off as your project/code base starts to grow larger as the chances of introducing bugs increases.

---

Unit-testing and TDD in general enables you to have shorter feedback cycles about the software you are writing. Instead of having a large test phase at the very end of the implementation, you incrementally test everything you write. This increases code quality very much, as you immediately see, where you might have bugs.

참고URL : https://stackoverflow.com/questions/1383/what-is-unit-testing