단위 테스트가 실행되는 동안 무슨 일이 일어나는지 보여 주시겠습니까? 내 단위 테스트를 코딩하고 따라

Question

, 나는 내가 다음 줄을 삽입 할 것을 찾는 경향이

Console.WriteLine("Starting InteropApplication, with runInBackground set to true..."); 
try 
{ 
    InteropApplication application = new InteropApplication(true); 
    application.Start(); 
    Console.WriteLine("Application started correctly"); 
} 
catch(Exception e) 
{ 
    Assert.Fail(string.Format("InteropApplication failed to start: {0}", e.ToString())); 
} 

//test code continues ... 

내 모든 시험은 거의 같은 일이다. 그들은 왜 그들이 실패했는지에 대한 정보를 표시하거나 자신이하는 일에 대한 정보를 표시합니다. 어떤 형식 테스트를 코딩하는 방법에 대한 방법이 없었습니다. 그들이 무엇을하고 있는지에 관한 정보를 표시해야합니까? 또는 테스트가 조용하고 그들이하는 일에 대한 정보를 전혀 표시하지 않고 오류 메시지 만 표시해야합니까?

참고 : 언어는 C#이지만 언어 별 답변은 신경 쓰지 않습니다.

Answer 1

개인적으로는 오류 만 출력하고 실행 한 테스트 수 및 통과 한 수에 대한 요약을 권장합니다. 이것은 완전히 주관적인 견해입니다. 자신의 필요에 맞는 것을 표시하십시오.

Answer 2

글쎄, 테스트가 실패한시기와 실패한 이유 만 알면됩니다. 예를 들어 루프가 있고 루프의 어느 부분에서 테스트가 종료되었는지 정확히 알고 싶지 않은 경우를 제외하고는 어떤 일이 벌어지고 있는지 알면 유용하지 않습니다.

Answer 3

나는 그것을 추천한다 - 나는 단위 테스트가 유닉스 툴 철학에서 작동해야한다고 생각한다. 일이 잘 풀릴 때 아무 말도하지 말아라. 오류가 발생했을 때 의미있는 정보를 제공하는 테스트를 만드는 것이 가장 좋습니다. 문제가 발생하면 문제가 무엇인지 잘못 판단하는 것이 쉽고, 실명을 스크롤하는 데 오류가 발생하지 않습니다.

Answer 4

내가 왜 그렇게 할 지 확신하지 않습니다. 단원 테스트의 이름이 잘 지정되어 있다면, 당신은 이미 무엇을하고 있는지 알 것입니다. 실패하면 어떤 테스트가 실패했는지 (그리고 실패한 이유는 무엇인지) 알 수 있습니다. 실패하지 않았다면 성공했음을 알 수 있습니다.

이것은 완전히 주관적이지만 나에게는 이것이 노이즈를 추가하는 완전히 중복 된 정보처럼 보입니다.

Answer 5

자세한 로그 (약 20 줄 정도)를 버퍼링하고 싶지만 오류가 발생할 때까지 표시하지 않습니다. 오류가 발생하면 상황을 파악하는 것이 좋습니다.

OTOH, 단위 테스트는 특정 입력 및 출력 요구 사항과 관련없는 작은 코드 여야합니다. 대부분의 경우 오류를 유발 한 입력 (즉 잘못된 출력)을 표시하면 문제를 뿌리까지 추적 할 수 있습니다.

Answer 6

나는 실제로 그것을 반대한다고 제안 할 것이다. 테스트의 사용자 인터페이스를 테스트 구현과 결합합니다 (테스트가 GUI 뷰어를 통해 실행되는 경우에는 어떻게됩니까?). 대안으로 나는 다음 중 하나를 제안 :

1. 내가 NUnit과 익숙하지 해요,하지만 PyUnit은 시험에 대한 설명을 추가 할 수 있습니다 및 테스트는 자세한 옵션으로 실행하는 경우에 대한 설명이 인쇄됩니다. 이것이 당신이 할 수있는 일인지 알기 위해 NUnit 문서를 살펴볼 것입니다.
   
2. 상속 받고자하는 TestCase 클래스를 확장하여 테스트에서 수행하려는 작업을 기록한 호출 함수를 추가하십시오. 그런 식으로 다른 구현은 다른 방법으로 메시지를 처리 ​​할 수 ​​있습니다.

Answer 7

이것은 언어별로 너무 다를 수도 있지만 NUnit 테스트를 작성할 때 필자는 System.Diagnostics를 사용합니다.콘솔 대신 추적 라이브러리를 사용하면 트레이스를보기로 결정한 경우에만 정보가 표시됩니다.

Answer 8

나는 당신이 훨씬 더 당신 자신을 위해 일한다고 생각합니다. 테스트가 통과하거나 실패하면 실패는 규칙의 예외가되어야하며 유닛 테스트 러너가 예외를 처리하고 예외를 발생하게해야합니다. 당신이하고있는 일은 cruft를 추가하는 것입니다, 테스트 주자가 기록한 예외는 당신에게 똑같은 것을 말할 것입니다.

Answer 9

나는 당신이 원하는대로 출력해야한다고 말하고 싶지만 너무 많이 보여 주면 테스트 주자의 출력이 희석 될 수 있습니다.
생각하면 예제 코드는 unit test, 더 많은 통합/시스템 테스트로 보이지 않습니다.

Answer 10

내가 무슨 일이 일어나고있는 지 알 수있는 유일한 시간은 비 자동적으로 테스트하기가 더 쉽다는 것입니다. 예를 들어, 실행하는 데 시간이 걸리고 무한 루프에 걸릴 수있는 코드가있는 경우 메시지가 너무 자주 인쇄되어 계속 진행되고 있음을 나타낼 수 있습니다.

그러나 항상 오류 메시지가 다른 출력물과 뚜렷하게 구분되도록하십시오.

Answer 11

테스트가 자동으로 실행 중이면 오류가 없음을 의미하지 않습니다. 일반적으로 테스트가 실패한 경우가 아니면 테스트 결과가 출력 될 이유가 없습니다. 실행 중이면 테스트가 통과 한 테스트 주자, 즉 "녹색"으로 표시된 실행 중입니다. IDE에서 테스트 러너를 통해 테스트 (콘솔 출력으로 여러 테스트와 함께)를 실행하면 아무도 신경 쓰지 않는 메시지로 콘솔 로그를 스팸하게됩니다.

작성한 테스트는 단위 테스트가 아니지만 전체적으로 응용 프로그램을 실행하고있는 것처럼 보이기 때문에 통합/시스템 테스트와 비슷합니다. 단원 테스트는 클래스의 공용 메서드를 테스트합니다. 가능하면 클래스를 가능한 한 격리 된 상태로 유지하는 것이 좋습니다.

Answer 12

이와 같은 테스트 방법을 작성했을 수 있습니다. 그것은 당신이 선호하는 테스트 스타일을 코드에 따라 다릅니다. 나는 try-catch와 Console.WriteLines을 쓰지 않는 편이 좋다. 내가 일한

public void TestApplicationStart() 
{ 
    InteropApplication application = new InteropApplication(true); 
    application.Start(); 
} 

테스트 프레임 워크는 실패한 테스트로 처리되지 않은 (예상치 못한) 예외를 해석하는 것입니다.

이 테스트를 수행 한 시간과 그 동안 얼마나 많은 의미있는 테스트를 작성했는지 생각해보십시오.

Answer 13

콘솔 I/O를 사용하면 단위 테스트 프레임 워크의 전체 목적을 무시합니다. 수동으로 전체 테스트를 코딩 할 수도 있습니다. 단위 테스트 프레임 워크를 사용하는 경우 테스트는 매우 가단해야하며 가능한 한 적은 것으로 묶어야합니다.

Answer 14

표시 정보가 유용 할 수 있습니다. 테스트가 실패한 이유를 찾으려는 경우 스택 추적 이상을 볼 수 있고 프로그램이 실패한 지점에 도달하기 전에 어떤 일이 발생했는지 파악하는 것이 유용 할 수 있습니다.

그러나 모든 것이 성공한 "정상적인"경우에는 이러한 메시지가 실제로는 무엇을해야하는지 혼란스럽게하는 불필요한 혼란입니다. 어떤 테스트가 성공하고 실패했는지에 대한 개요를 살펴 봅니다.

디버깅 메시지를 로그 파일로 리디렉션하는 것이 좋습니다. 특별한 "로그 인쇄"기능을 호출하기 위해 모든 로그 메시지 코드를 작성하거나 콘솔 프로그램을 작성하는 경우 stdout을 다른 파일로 리디렉션 할 수 있어야합니다 (사실은 Unix와 Windows 모두에서이 작업을 수행 할 수 있습니다). 이렇게하면 높은 수준의 개요를 얻을 수 있지만 필요한 경우 세부 정보가 표시됩니다.

Answer 15

단위 테스트에 추가 Try/Catch 문을 넣지 마십시오. 우선 단위 테스트에서 예상되는 예외로 인해 이미 테스트가 실패하게됩니다. 이것은 NUnit의 기본 동작입니다. Essential, 테스트 하니스는 이미 테스트 함수에 대한 각 호출을 해당 코드로 래핑합니다. 또한 e.ToString()을 사용하여 무슨 일이 있었는지 표시함으로써 나는 많은 정보를 잃어 버리고 있다고 생각합니다. 기본적으로 NUnit에는 예외 유형뿐만 아니라 호출 스택이 표시 될 것으로 믿습니다.이 스택은 사용자의 메서드로는 보이지 않습니다.

둘째, 필요할 때가 있습니다. 예를 들어 [ExpectedException] 특성을 사용하여 실제로 발생하는 시점을 말할 수 있습니다. Assert에 대한 인수로 좋은 설명을 넣은 비 예외 관련 Assert (예 : 목록 개수> 0 등)를 테스트 할 때 반드시 확인해야합니다. 유용합니다.

다른 모든 것은 일반적으로 필요하지 않습니다. 유닛 테스트가 너무 커서 WriteLines에 테스트의 "단계"를 넣기 시작하면 일반적으로 테스트가 실제로 여러 개의 작은 테스트로 나누어 져야한다는 신호가됩니다. 즉, 단원 테스트를 수행하는 것이 아니라 통합 테스트를 수행한다는 것입니다.

Answer 16

단위 테스트 프레임 워크의 xUnit 스타일을 살펴 보셨습니까?
다소 큰 목록은 Ron Jeffries 사이트를 참조하십시오.

이러한 프레임 워크의 원칙 중 하나는 테스트 실행 중에 출력이 거의 또는 전혀 출력되지 않고 실제로는 성공의 지표 일 뿐이라는 것입니다. 실패의 경우에는 실패 이유를보다 구체적으로 출력 할 수 있습니다.
이 모드의 이유는 모든 것이 정상이지만 여분의 출력에 신경을 쓰고 싶지 않고 실패가 발생하면 다른 출력의 노이즈 때문에 놓치고 싶지 않기 때문입니다.