수정 된 후에 만 ​​테스트 할 수있는 버그를 어떻게 TDD 할 수 있습니까?

예를 들면 다음과 같습니다. 웹 응용 프로그램에 드래그 가능한 요소가 있습니다. 요소를 드래그하면 브라우저가 "고스트 이미지"를 생성합니다. 드래그 할 때 "고스트 이미지"를 제거하고이 동작에 대한 테스트를 작성하려고합니다.

내 문제는 처음 에이 버그를 수정하는 방법을 모르고 테스트를 작성할 수있는 유일한 방법은 수정 한 것입니다.

와 같은 간단한 함수에서 코드를 작성하기 전에 let sum = (a, b) => a - b왜 sum(1, 2)같지 않은지 테스트 할 수 있습니다 3.

설명하는 경우 검증이 무엇인지 알 수 없기 때문에 테스트 할 수 없습니다 (어설 션이 무엇인지 모르겠습니다).

설명 된 문제에 대한 해결책은 다음과 같습니다.

let dataTransfer = e.dataTransfer
let canvas = document.createElement('canvas');
canvas.style.opacity = '0';
canvas.style.position = 'absolute';
canvas.style.top = '-1000px';
dataTransfer.effectAllowed = 'none';

document.body.appendChild(canvas);
dataTransfer.setDragImage(canvas, 0, 0);

이것이 해결책이라는 것을 알 수 없었습니다. 실제로 솔루션이 실제로 작동하는지 알 수있는 유일한 방법은이 코드를 코드베이스에 추가하고 원하는 효과가 있는지 브라우저로 확인하기 때문에 솔루션을 온라인으로 찾은 후에도 테스트를 작성할 수 없었습니다. 테스트는 코드 다음에 작성되어야했으며 이는 TDD에 반합니다.

이 문제에 대한 TDD 접근법은 무엇입니까? 코드 작성 전에 테스트를 작성해야합니까?

올바르게 이해하면 솔루션을 찾은 후 "고스트 이미지"예제에 대해 신뢰할 수있는 자동화 된 테스트를 작성할 수 없습니다 . 올바른 동작을 확인하는 유일한 방법은 화면을보고 고스트 이미지가 없는지 확인하는 것입니다. 더 이상. 그것은 당신의 오리지널 헤드 라인이 잘못된 질문을했다는 인상을줍니다. 진짜 질문은

• 그래픽 사용자 인터페이스의 특정 동작을 자동으로 테스트하는 방법은 무엇입니까?

그리고 몇 가지 UI 문제에 대한 대답은 그렇지 않습니다 . 물론 UI가 어떻게 든 문제를 보여주는 자동화를 시도하고 스크린 샷 비교와 같은 것을 구현하려고 시도 할 수 있지만 종종 오류가 발생하기 쉽고 취성이며 비용 효율적이지 않습니다.

특히 미리 작성된 자동 테스트를 통한 "테스트 운전"UI 디자인 또는 UI 개선은 사실상 불가능합니다. 개선하여 UI 디자인을 "구동"하고 결과를 사람 (자신, 일부 테스터 또는 사용자)에게 보여주고 피드백을 요청합니다.

따라서 TDD가 은총 알이 아니라는 사실을 받아들이십시오. 어떤 종류의 문제에 대해서는 수동 테스트가 자동 테스트보다 더 의미가 있습니다. 일부 전담 테스터와 함께 체계적인 테스트 프로세스를 수행하는 경우 테스트 계획에 사례를 추가하는 것이 가장 좋습니다.

이 문제에 대한 TDD 접근법은 무엇입니까? 코드 작성 전에 테스트를 작성해야합니까?

한 가지 방법은 스파이크 솔루션 의 아날로그를 적용하는 것 입니다.

James Shore 는 다음과 같이 설명했습니다.

더 많은 정보가 필요할 때 소규모의 고립 된 실험을 수행합니다.

기본 아이디어 는 진행중인 작업을 파악하면서 디자인 도구를 내려 놓는 것입니다. 베어링이 있으면 디자인 도구를 다시 선택합니다.

트릭 : 조사에서 얻은 지식 을 프로덕션 코드 기반으로 다시 가져 오지만 코드를 가져 오지는 않습니다 . 대신, 훈련 된 설계 기술을 사용하면서이를 재 작성하십시오.

코스 말.

편집하다:

결함이 육안으로 만 보이는 경우 어떻게 테스트를 자동화 할 수 있습니까?

"테스트 자동화가 비용 효율적이지 않은 경우 어떻게 테스트를 자동화 할 수 있습니까?"

물론 대답은 "그렇지 않습니다"입니다. 대신 구현이 두 부분으로 분리되도록 노력하십시오. 테스트가 비용 효과적인 부분과 깨지기 어려운 부분입니다.

소프트웨어 설계는 두 가지 방법으로 구성 할 수 있습니다. 한 가지 방법은 결함이 없도록 간단하게 만드는 것입니다. CAR Hoare

따라서 써드 파티 코드로 작업 할 때 써드 파티 라이브러리의 프록시 역할을하는 매우 얇은 코드 쉘을 갖게됩니다. 테스트에서, 우리는 그 쉘을 "test double"로 대체 하여 원하는 효과를 생성 할까 걱정하지 않고 프로토콜 을 검증합니다 .

실제 타사 코드와의 코드 통합 테스트를 위해 다른 기술 (시각 검증, 기술 지원 요청, 낙관론)에 의존합니다.

일부 데모 아티팩트를 유지하면 써드 파티 라이브러리를 업그레이드 할 때 가정이 여전히 유지되는지 확인할 수 있습니다.

단지 다른 관점에서 UI / GUI에 대한 테스트는 수용 테스트 (기능 / 비즈니스 워크 플로우 중심 테스트)와 관련하여 약간 더 잘 수행 될 수 있습니다.

웹의 경우 셀레늄 웹 드라이버와 같은 프레임 워크가 올바른 테스트에 근접 할 가능성이 있다고 생각하지만 시작하는 데 약간의 오버 헤드가있을 수 있으며 단위 테스트와 관련하여 TDD에서 볼 수있는 흐름의 변화입니다 .

상황에 특히 도움이되는 부분은 페이지 객체 모델 ( https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html )입니다. 이를 통해 메소드 / 이벤트 / 클래스 멤버의 이름을 지정하여 런타임 GUI를 일부 코드에 명시 적으로 맵핑 할 수 있습니다.

이것에 대한 주요 주장은 오버 헤드이며,이 오버 헤드는 일반적으로 개발주기의 끝에서 볼 수 있습니다. 테스트에 중복 된 작업을 생성하는 것처럼 보이는 래퍼가 필요하다는 오버 헤드가 있습니다.

앞으로는 팀과 비즈니스의 비용 / 혜택에 의존하므로 기대와 견해를 결정하기 위해 논의하는 것이 유익한 주제가 될 수 있습니다.

고스트 이미지는 어떻게 생겼습니까? 알려진 색상의 더미 UI를 만든 경우 드래그 가능한 구성 요소를 어디에 배치합니까? 유령 이미지가있는 경우 특정 색상이 존재합니까?

그런 다음 테스트에서 고스트 이미지의 색상이 없는지 테스트 할 수 있습니다.

이러한 테스트는 합리적이고 내구성이 뛰어납니다.