내가 TDD에 대해 알게 된 것은 테스트를 설정하는 데 시간이 걸리고 자연스럽게 게으르다는 것입니다. 저는 항상 가능한 한 적은 코드를 작성하고 싶습니다. 내가하는 첫 번째 일은 내 생성자가 모든 속성을 설정했지만 이것이 과잉입니까?
내 질문은 단위 테스트를 어떤 수준으로 작성합니까?
.. 너무 많은 테스트 사례가 있나요?
답변
나는 테스트가 아니라 작동하는 코드에 대해 돈을 받는다. 그래서 나의 철학은 주어진 신뢰 수준에 도달하기 위해 가능한 한 적은 테스트를하는 것이다. . 일반적으로 생성자에 잘못된 변수를 설정하는 것과 같은 실수를하지 않으면 테스트하지 않습니다. 나는 테스트 오류를 이해하는 경향이 있으므로 복잡한 조건이있는 논리가있을 때 특히주의합니다. 팀에서 코딩 할 때, 저는 우리가 전체적으로 잘못되는 경향이있는 코드를 신중하게 테스트하기 위해 전략을 수정합니다.
다른 사람들은이 철학에 기반한 다른 테스트 전략을 가지고있을 것이지만, 테스트가 코딩의 내부 루프에 가장 잘 맞을 수있는 방법에 대한 미성숙 한 이해 상태를 감안할 때 나에게는 합리적으로 보입니다. 이제 10 년 또는 20 년 후에 우리는 어떤 테스트를 작성하고, 어떤 테스트를 작성하지 않으며, 차이점을 어떻게 구분하는지에 대한보다 보편적 인 이론을 갖게 될 것입니다. 그 동안 실험은 순서대로 보인다.
답변
깨질 것으로 예상되는 항목과 엣지 케이스에 대한 단위 테스트를 작성하십시오. 그 후에 버그에 대한 수정을 작성하기 전에 버그 보고서가 들어 오면 테스트 케이스를 추가해야합니다. 개발자는 다음을 확신 할 수 있습니다.
- 버그가 수정되었습니다.
- 버그가 다시 나타나지 않습니다.
첨부 된 주석에 따라-시간이 지남에 따라 주어진 클래스에서 많은 버그가 발견되면 단위 테스트 작성에 대한 이러한 접근 방식이 문제를 일으킬 수 있다고 생각합니다. 이것은 아마도 재량권이 도움이 될 것입니다.-다시 발생할 가능성이있는 버그에 대해서만 단위 테스트를 추가하거나 그 재발이 심각한 문제를 일으킬 수있는 곳입니다. 단위 테스트에서 통합 테스트의 척도가 이러한 시나리오에서 도움이 될 수 있음을 발견했습니다. 상위 코드 경로를 테스트하면 하위 코드 경로를 포함 할 수 있습니다.
답변
모든 것이 가능한 한 단순해야하지만 더 단순해서는 안됩니다. -A. 아인슈타인
TDD에 대해 가장 오해받는 것 중 하나는 그 안에있는 첫 번째 단어입니다. 테스트. 이것이 BDD가 등장한 이유입니다. 사람들은 첫 번째 D가 중요한 것, 즉 Driven이라는 것을 실제로 이해하지 못했기 때문입니다. 우리 모두는 테스트에 대해 조금 또는 많이 생각하고 디자인 추진에 대해 조금 또는 조금 생각하는 경향이 있습니다. 그리고 이것은 귀하의 질문에 대한 모호한 대답이라고 생각합니다. 그러나 실제로 테스트하는 대신 코드를 구동하는 방법을 고려해야합니다. 그것은 Coverage-tool이 당신을 도울 수있는 것입니다. 디자인은 훨씬 더 크고 문제가되는 문제입니다.
답변
“모든 것”테스트를 제안하는 사람들에게 : “완전히 테스트”하는 방법 int square(int x)은 공통 언어 및 일반적인 환경에서 약 40 억 개의 테스트 케이스가 필요 하다는 것을 인식하십시오 .
사실, 그보다 훨씬 더 나쁜 : 방법은 void setX(int newX)또한 의무가 없습니다 이외의 다른 멤버의 값을 변경하는 x– 당신이를 테스트하고 obj.y, obj.z모든 호출 한 후 변경되지 않은 상태로 유지 등 obj.setX(42);?
“모든 것”의 일부만 테스트하는 것이 실용적입니다. 이것을 받아 들인 후에는 믿을 수 없을 정도로 기본적인 행동을 테스트하지 않는 것을 고려하는 것이 더 맛있어집니다. 모든 프로그래머는 버그 위치 의 확률 분포 를 가지고 있습니다. 현명한 접근 방식은 버그 확률이 높을 것으로 예상되는 테스트 지역에 에너지를 집중하는 것입니다.
답변
고전적인 대답은 “파손될 수있는 모든 것을 테스트”하는 것입니다. set 또는 get 외에는 아무것도하지 않는 setter와 getter를 테스트하는 것이 아마도 너무 많은 테스트이므로 시간이 걸리지 않는다는 의미로 해석합니다. IDE가 당신을 위해 작성하지 않는 한, 당신도 그렇게 할 수 있습니다.
생성자 가 속성을 설정 하지 않으면 나중에 오류가 발생할 수있는 경우 해당 속성이 설정되었는지 테스트하는 것은 과도하지 않습니다.
답변
내가 작성할 클래스의 가정을 다루기 위해 테스트를 작성합니다. 테스트는 요구 사항을 적용합니다. 본질적으로, 예를 들어 x가 절대 3 일 수없는 경우 해당 요구 사항을 충족하는 테스트가 있는지 확인하겠습니다.
변함없이 조건을 다루는 테스트를 작성하지 않으면 나중에 “인간”테스트 중에 나타납니다. 나는 확실히 그때 하나를 쓸 것이지만, 나는 그들을 일찍 잡을 것이다. 요점은 테스트가 지루하지만 (아마도) 필요하다는 것입니다. 나는 완료하기에 충분한 테스트를 작성하지만 그 이상은 아닙니다.
답변
지금 간단한 테스트를 건너 뛰는 문제의 일부는 향후 리팩토링으로 인해 많은 논리로 인해 간단한 속성이 매우 복잡해질 수 있다는 것입니다. 가장 좋은 아이디어는 테스트를 사용하여 모듈의 요구 사항을 확인할 수 있다는 것입니다. X를 통과했을 때 Y를 되 찾아야한다면 그것이 테스트하고 싶은 것입니다. 그런 다음 나중에 코드를 변경할 때 X가 Y를 제공하는지 확인하고 나중에 해당 요구 사항이 추가 될 때 A에 대한 테스트를 추가하여 B를 제공 할 수 있습니다.
초기 개발 테스트를 작성하는 동안 보낸 시간이 첫 번째 또는 두 번째 버그 수정에서 효과가 있다는 것을 발견했습니다. 3 개월 동안 살펴 보지 않은 코드를 선택하고 수정 사항이 모든 경우를 다루고 “아마도”어떤 것도 손상시키지 않는지 합리적으로 확신 할 수있는 능력은 매우 중요합니다. 또한 단위 테스트는 스택 추적을 넘어서는 버그를 분류하는 데 도움이된다는 것을 알게 될 것입니다. 앱의 개별 부분이 작동하고 실패하는 방식을 확인하면 전체적으로 작동하거나 실패하는 이유에 대한 큰 통찰력을 얻을 수 있습니다.
