단위 테스트 란 무엇이며 어떻게 수행합니까?

단위 테스트 란 무엇이며 어떻게 수행합니까? [복제]

---

많은 게시물의 정확한 복제본 :

단위 테스트 란 무엇입니까?
좋은 단위 테스트는 무엇입니까?
단위 테스트를 처음 사용하는 단위 테스트
-정의
학습 단위 테스트
올바르게 모의 및 단위 테스트를 수행 하는 방법
단위 테스트 : 초보자 질문
및 기타 ...
또한 Google 사이트 : stackoverflow.com "어떻게 지내 십니까? "단위 테스트

단위 테스트에 대한 몇 가지 질문을 읽었지만 그것이 무엇인지 또는 어떻게하는지 정확히 알지 못합니다. 누군가 다음을 말해 줄 수 있기를 바랐습니다.

• 정확히 단위 테스트 란 무엇입니까? 코드에 내장되어 있거나 별도의 프로그램으로 실행됩니까? 또는 다른 것?
• 어떻게합니까?
• 언제해야합니까? 하지 말아야 할 시간이나 프로젝트가 있습니까? 모든 것이 단위 테스트 가능합니까?

도움을 주셔서 감사합니다.

---

단위 테스트에는 프로그램을 여러 조각으로 나누고 각 조각을 일련의 테스트를 거치게됩니다.

일반적으로 테스트는 별도의 프로그램으로 실행되지만 테스트 방법은 언어 및 소프트웨어 유형 (GUI, 명령 줄, 라이브러리)에 따라 다릅니다.

대부분의 언어에는 단위 테스팅 프레임 워크 가 있으므로 자신의 언어 를 살펴보아야합니다.

테스트는 대개 소스 코드가 변경 될 때마다 정기적으로 실행됩니다. 빨리 문제를 잡을 수 있기 때문에 더 자주 더 좋습니다.

---

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

단위 테스트는 단순히 개별 코드 단위 (주로 기능)가 예상대로 작동하는지 확인합니다. 일반적으로 테스트 사례를 직접 작성하지만 일부는 자동으로 생성 될 수 있습니다.

테스트의 출력은 콘솔 출력, NUnit 과 같은 GUI 의 " 녹색 표시 등 " 또는 다른 언어 별 프레임 워크 로 간단 할 수 있습니다 .

단위 테스트 수행은 간단하도록 설계되었습니다. 일반적으로 테스트는 반환 된 값이 함수를 작성할 때 예상했던 값과 같거나 최종적으로 작성할 때 예상 되는 값과 같은지 여부를 결정하는 함수 형태 로 작성됩니다. 테스트를 먼저 작성할 때 이를 테스트 중심 개발 이라고 합니다.

단위 테스트는 어떻게 수행합니까?

테스트하려는 매우 간단한 함수를 상상해보십시오.

int CombineNumbers(int a, int b) {
    return a+b;
}

단위 테스트 코드는 다음과 같습니다.

void TestCombineNumbers() {
    Assert.IsEqual(CombineNumbers(5, 10), 15); // Assert is an object that is part of your test framework
    Assert.IsEqual(CombineNumbers(1000, -100), 900);
}

테스트를 실행하면 테스트가 통과되었다는 메시지가 표시됩니다. 테스트를 빌드하고 실행 했으므로이 특정 기능 또는 단위가 예상대로 수행 될 것입니다.

이제 다른 개발자가 와서 CombineNumbers()성능 또는 다른 이유로 기능을 변경한다고 상상해보십시오 .

int CombineNumbers(int a, int b) {
    return a * b;
}

개발자가이 매우 간단한 함수에 대해 생성 한 테스트를 실행하면 첫 번째 Assert오류가 발생하고 빌드가 손상되었음을 알게됩니다.

언제 단위 테스트를 수행해야합니까?

가능한 한 자주 수행해야합니다. 개발 프로세스의 일부로 테스트를 수행하는 경우 함수를 작성한 다음 계속하는 것보다 코드가 자동으로 더 잘 설계됩니다. 또한 Dependency Injection 과 같은 개념 은 자연스럽게 코드로 발전 할 것입니다.

가장 명백한 이점은 변경이 이루어질 때 모든 개별 코드 단위가 테스트를 통과하면 영향을받지 않는다는 것입니다.

---

뭐...

원하는 결과를 시행하고 변경을 관리하도록 설계된 일련의 테스트에 대해 코드를 자동으로 테스트하는 방법론.

이러한 의미에서 "단위"는 테스트하기에 적합한 코드의 가장 작은 원자 구성 요소입니다 (예 : 일반적으로 일부 클래스의 메소드). 이 프로세스의 일부는 유닛과 독립된 오브젝트로 작업 할 수있는 스텁 오브젝트 (또는 "mocks")를 빌드하는 것입니다.

어떻게...

거의 항상 단위 테스팅 프로세스는 모든 컴파일마다 테스트를 실행하도록 IDE (또는 확장 기능)에 내장되어 있습니다. 종종 foo Unit (cf. jUnit, xUnit, nUnit)으로 불리는 단위 테스트 (및 실제로 모의 객체) 생성을 지원하기위한 많은 프레임 워크가 존재합니다 . 이 프레임 워크는 공식적인 테스트 작성 방법을 제공합니다.

As a process, test driven development (TDD) is often the motivation for unit testing (but unit testing does not require TDD) which supposes that the tests are a part of the spec definition, and therefore requires that they are written first, with code only written to "solve" these tests.

When...

Almost always. Very small, throwaway projects may not be worth it, but only if you're quite sure they really are throwaway. In theory every object orientated program is unit testable, but some design pattrns make this difficult. Notoriously, the singleton pattern is problematic, where conversely dependancy injection frameworks are very much unit testing oriented.

---

What is unittesting? It is tricky to define. On a technical level, you build functions that call functions in your codebase and validate the results. Basically, you get a bunch of things like "assert(5+3) == 8", just more complicated (as in DataLayer(MockDatabase()).getUser().name == "Dilbert"). On a tool-view-level, you add an automated, project-specific check if everything still works like you assumed things worked. This is very, very helpful if you refactor and if you implement complicated algorithms. The result generally is a bunch of documentation and a lot less bugs, because the behaviour of the code is pinned down.

I build test cases for all the edge cases and run them similar to the workings of a generational garbage collector. While I implement a class, I only run the test cases that involve the class. Once I am done with working on that class, I run all unittests in order to see if everything still works.

You should test as much as possible, as long as the test code is easy enough to stay untested. Given that, no, not everything is testable in a sane way. Think User interfaces. Think a driver for a space shuttle or a nuclear bomb (at least not with pure JUnit-tests ;) ). However, lots and lots of code is testable. Datastructures are. Algorithms are. Most Applicationlogic-classes are. So test it!

HTH. tetha

---

I find the easiest way to illustrate it is to look at some code. This getting started page on the NUnit site is a good introduction to the what and the how

http://www.nunit.org/index.php?p=quickStart&r=2.5

Is everything testable? Generally if it calculates something then yes. UI code is a whole other problem to deal with though, as simulating users clicking on buttons is tricky.

What should you test? I tend to write tests around the things I know are going to be tricky. Complicated state transitions, business critical calculations, that sort of thing. Generally I'm not too worried about testing basic input/output stuff, although the purists will doubtless say I'm wrong on that front and everything should be tested. Like so many other things, there is no right answer!

---

What exactly IS unit testing? Is it built into code or run as separate programs? Or something else?

From MSDN: The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

Essentially, you are writing small bits of code to test the individual bits of your code. In the .net world, you would run these small bits of code using something like NUnit or MBunit or even the built in testing tools in visual studio. In Java you might use JUnit. Essentially the test runners will build your project, load and execute the unit tests and then let you know if they pass or fail.

How do you do it?

Well it's easier said than done to unit test. It takes quite a bit of practice to get good at it. You need to structure your code in a way that makes it easy to unit test to make your tests effective.

When should it be done? Are there times or projects not to do it? Is everything unit-testable?

You should do it where it makes sense. Not everything is suited to unit testing. For example UI code is very hard to unit test and you often get little benefit from doing so. Business Layer code however is often very suitable for tests and that is where most unit testing is focused.

Unit testing is a massive topic and to fully get an understanding of how it can best benefit you I'd recommend getting hold of a book on unit testing such as "Test Driven Development by Example" which will give you a good grasp on the concepts and how you can apply them to your code.

---

On the "How to do it" part:

I think the introduction to ScalaTest does good job of illustrating different styles of unit tests.

On the "When to do it" part:

Unit testing is not only for testing. By doing unit testing you also force the design of the software into something that is unit testable. Many people are of the opinion that this design is for the most part Good Design(TM) regardless of other benefits from testing.

So one reason to do unit test is to force your design into something that hopefully will be easier to maintain that what it would be had you not designed it for unit testing.

참고URL : https://stackoverflow.com/questions/652292/what-is-unit-testing-and-how-do-you-do-it