단위 테스트에 대해 말할 때“DAMP not DRY”는 무엇을 의미합니까?

누군가 단위 테스트 (예 : nUnit, jUnit, xUnit)가

건조 하지 않은 습기

(예 : 단위 테스트에는 "건조 코드"가 아닌 "습기 코드"가 포함되어야 함)

그들은 무엇에 대한 이야기?

모순이 아니라 균형입니다

DAMP와 DRY는 모순되지 않으며 코드 유지 관리 의 두 가지 측면을 균형있게 조정 합니다 . 유지 관리 가능한 코드 (변경하기 쉬운 코드)는 여기서 궁극적 인 목표입니다.

DAMP (Descriptive And Meaningful Phrase)는 코드 의 가독성 을 향상시킵니다.

코드를 유지하려면 먼저 코드를 이해해야합니다. 그것을 이해하려면 읽어야합니다. 코드를 읽는 데 시간이 얼마나 걸리는지 잠시 생각해보십시오 . 많이입니다. DAMP는 코드를 읽고 이해하는 데 필요한 시간을 줄여 유지 보수성을 향상시킵니다.

DRY (반복하지 말 것)는 코드 의 직교성 을 촉진합니다 .

중복을 제거하면 시스템의 모든 개념이 코드에서 하나의 권위있는 표현을 갖습니다. 단일 비즈니스 개념을 변경하면 코드가 단일로 변경됩니다. DRY는 변경해야하는 시스템 부분에만 변경 (위험)을 격리하여 유지 관리 성을 향상시킵니다.

테스트에서 왜 복제가 더 수용 가능한가?

테스트에는 입력 값이나 설정 코드가 약간 다른 동일한 테스트를 반복해서 반복하기 때문에 고유 중복이 포함되는 경우가 많습니다. 그러나 프로덕션 코드와 달리이 복제는 일반적으로 단일 테스트 픽스처 / 파일 내의 시나리오에만 격리됩니다. 이로 인해 복제가 최소화되고 분명 해져 다른 유형의 복제보다 프로젝트에 대한 위험이 줄어 듭니다.

또한 이러한 종류의 복제를 제거하면 테스트의 가독성이 떨어집니다. 각 테스트에서 이전에 복제 된 세부 정보는 이제 일부 새로운 메서드 또는 클래스에 숨겨져 있습니다. 테스트의 전체 그림을 얻으려면 이제이 모든 조각을 정신적으로 다시 결합해야합니다.

따라서 테스트 코드 복제는 종종 위험을 줄이고 가독성을 높이기 때문에 어떻게 수용 가능한지 쉽게 알 수 있습니다.

원칙적으로 프로덕션 코드에서 DRY를 선호하고 테스트 코드에서 DAMP를 선호하십시오. 둘 다 똑같이 중요하지만 약간의 지혜로 균형을 유리하게 기울일 수 있습니다.

댐-설명적이고 의미있는 문구.

"DAMP not DRY"는 코드 재사용에 대한 가독성을 평가합니다. 테스트 사례에서 DAMP DRY가 아니라는 개념은 테스트 사례가 때때로 반복되는 코드를 의미하더라도 테스트를 이해하기 쉽다는 것입니다.

또한 단위 테스트에서 중복 코드가 더 견딜 수 있습니까? 이 관점의 장점에 대한 논의를 위해.

Jay Fields 가 도메인 특정 언어와 관련하여 만들었을 수도 있습니다 .

"DRY"는 "반복하지 마십시오"입니다

이것은 사람들에게 재사용 가능한 코드를 작성하도록 지시하는 용어로, 유사한 코드를 반복해서 작성하지 않도록합니다.

"DAMP"는 "설명적이고 의미있는 문구"입니다.

이 용어는 코드를보고있는 사람이 쉽게 이해할 수있는 코드를 작성하기위한 것입니다. 이 원칙을 따르는 경우 길고 설명 가능한 변수 및 함수 이름 등이 있습니다.

습기 = '설명적이고 의미있는 문구'-단위 테스트를 '읽을'수 있어야합니다.

중복 코드를 피하는 것보다 가독성이 중요합니다.

기사에서 :

DAMP는 "설명적이고 의미있는 문구"를 나타내며 "모든 것이 쓰레기 더미처럼 보이고 읽을 수 없음"이라는 의미가 아니라 DRY와 반대되는 의미입니다. 가독성은 중복 코드를 피하는 것보다 더 중요합니다.

이것이 무엇을 의미하며 어디에서 사용해야합니까?

DAMP는 주로 테스트 코드를 작성할 때 적용됩니다. 테스트 코드는 일부 중복성이 허용 될 정도로 이해하기 쉬워야합니다.

DAMP는 "설명적이고 의미있는 문구"를 나타내며 "모든 것이 쓰레기 더미처럼 보이고 읽을 수 없음"이라는 의미가 아니라 DRY와 반대되는 의미입니다. 가독성은 중복 코드를 피하는 것보다 더 중요합니다.

http://codeshelter.wordpress.com/2011/04/07/dry-and-damp-principles-when-developing-and-unit-testing/

여기에 몇 가지 답변이 있지만, 그들이 할 수있는만큼 설명해야한다고 생각하지 않았기 때문에 다른 것을 추가하고 싶었습니다.

DRY (반복하지 말 것)의 아이디어는 응용 프로그램 코드 에서 중복되거나 반복되는 코드를 피하고 싶다는 것입니다. 코드에서 여러 번 수행해야하는 작업이있는 경우 여러 곳에서 유사한 코드를 반복하는 것이 아니라 함수 또는 클래스가 있어야합니다.

이것은 꽤 잘 알려진 프로그래밍 개념입니다.

DAMP (Descriptive and Meaninful Phrases)는 단위 테스트를위한 것입니다. 여기서 아이디어는 단위 테스트 방법 이름이 길고 설명 적이어야한다는 것입니다. 실제로 테스트 대상을 설명하는 짧은 문장입니다.

예 : testWhenIAddOneAndOneIShouldGetTwo() { .... }

이와 같은 DAMP 메소드 이름을 읽을 때 테스트 코드를 읽을 필요없이 테스트 작성자가 달성하려는 내용을 정확하게 이해해야합니다 (테스트 코드는 물론이 변수도 많은 변수 이름을 사용할 수 있지만, 기타).

이는 단위 테스트 방법에 매우 특정한 입력 및 예상 출력이 있기 때문에 가능합니다. 따라서 DAMP 원리가 적합합니다. 기본 응용 프로그램 코드의 메서드는 특히 DRY 원칙을 염두에두고 작성한 경우 이와 같은 이름을 보증 할만큼 구체적이지 않을 수 있습니다.

DAMP와 DRY는 서로 모순되지 않습니다. 코드 작성 방식의 다양한 측면을 다루지 만 DRY 원칙을 염두에두고 작성된 방법은 범용적이고 적합하지 않기 때문에 일반적으로 함께 사용되지 않습니다. 매우 구체적인 분석법 이름. 따라서 일반적으로 위에서 설명한대로 애플리케이션 코드는 DRY이고 단위 테스트 코드는 DAMP 여야합니다.

나는 그것이 조금 더 잘 설명하는 데 도움이되기를 바랍니다.

크리스 에드워즈 (Chris Edwards)에 동의합니다. 주의해야 할 또 다른 사항은 중복을 제거하기 위해 단위 테스트 코드에 많은 추가 구조를 추가하면 (즉, DRY를 극단적으로 수행 할 때) 버그가 발생할 위험이 있다는 것입니다. 이러한 상황에서는 단위 테스트를 단위 테스트하거나 구조 비트를 테스트하지 않은 상태로 두어야합니다.

여기에 노력을 복제하고 싶지 않지만 DAMP 테스트는 있지만 DRY의 이점을 얻을 수 있습니다. 반대로, DRY 테스트는 경우에 따라 DAMP 테스트를 만족하지 않습니다.

몇 가지 예를 포함하여 DRY vs DAMP에 대해 블로그했습니다.

두 가지 접근 방식이 유일한 솔루션이 아니어야하며 때로는 DAMP가 과도하게 사용되는 경우도 있습니다.

일반적으로 세 가지 규칙을 적용해야합니다. 중복을 세 번 발견하면 DAMP 스타일 테스트를 작성하는 것이 좋습니다. 그러나 모든 복제가 나쁘지는 않습니다 . 상황이 중요합니다.