모든 것을 테스트해야합니까?

Ruby on Rails 에서 첫 번째 실제 프로젝트를 시작하고 TDD 테스트 를 작성하도록 강요 합니다. 테스트를 작성하는 데 실제 이점은 보이지 않지만 매우 중요해 보이므로 시도해 보겠습니다.

정적 페이지를 포함하여 내 응용 프로그램의 모든 부분 을 테스트해야 합니까?

TDD는 테스트에 관한 것이 아니라 디자인에 관한 것입니다. 테스트를 작성하면 클래스의 작동 방식과 필요한 인터페이스에 대해 생각해야합니다. 테스트는 나중에 쉽게 리팩토링 할 수있게 해주는 즐거운 부작용입니다.

따라서이를 염두에두고 정적 페이지의 동작은 무엇이며 인터페이스는 무엇입니까?

나의 첫 반응은 "없음"과 "없음"입니다.

항상 비용-이익 분석입니다. 기능 비용이 얼마입니까? 비용이 높으면 잘 테스트하십시오. 비용이 낮 으면 가볍게 테스트하거나 전혀 테스트하지 마십시오.

시장 출시 시간도 고려해야합니다. 완전히 작동하는 기능을 늦게 제공하는 것보다 대부분 작동하는 기능을 제공하는 것이 좋습니다.

일반적인 IMO에서 이러한 질문에 대답하는 것은 거의 불가능합니다.

일부 기능이 원래 실현 한 것보다 더 중요한 경우 테스트 기능을 유지하는 것이 더 중요하다고 생각합니다.

나는 "예"라고 말할 것입니다. 가장 간단한 기능과 코드까지 테스트 한 경우 새 코드를 추가해도 내부 코드가 작동하지 않을 것이라는 확신을 가질 수 있습니다. 마찬가지로, 발생하는 모든 버그에 대해 테스트를 수행하면 회귀가 다시 발생하지 않습니다.

예, 모든 것을 테스트해야합니다 ...

모든 것에 대해 자동 테스트를 작성할 필요는 없습니다. 정적 페이지의 경우 Selenium http://seleniumhq.org/ 를 사용하여 내용이 올바른지 확인하십시오.

내 경험상 테스트 사례를 작성하는 것이 불가능한 일부 프론트 엔드 항목이지만 실제로 Mark 1 안구를 사용하여 테스트하려고합니다.

테스트는 코딩만큼 중요합니다. "무언가 잘못 될 수 있다면"이라는 말을 들어야합니다. INMO, 품질 향상을 위해 사용되는 수많은 소프트웨어 엔지니어링 기술 중에서 테스팅은 문제를 조기에 발견하는 데 가장 유용한 기술입니다.

모든 팀을 테스트 할 수는 없지만 (특히 소규모 팀과 대규모 시스템에서) 테스트를 건너 뛰는 것은 아닙니다. 테스트 가치가 있습니까? Wiki-SoftwareTesting의 "오류 조기 발견"섹션을 참조하십시오 .

그런 식으로 작성된 경우 TDD 테스트는 실제 사양이 될 수도 있습니다. 테스트 방법의 이름은 비즈니스 사용자에게 적합해야합니다.

다른 사람들이 언급했듯이 Ruby on Rails 테스트에서는 다른 언어보다 훨씬 중요합니다. 이것은 컴파일러가 없기 때문입니다.

Delphi , C ++, VB.NET 등과 같은 언어 는 컴파일 된 언어이며, 컴파일러는 메소드 호출에서 오타와 같은 많은 실수를 선택합니다. Ruby on Rails에서는 특정 코드 줄이 실행되거나 시각적 경고를 표시하는 IDE를 사용하는 경우 코드에 오타 나 실수가 있는지 여부 만 알 수 있습니다.

모든 한 줄의 코드가 중요하기 때문에 (그렇지 않은 경우) 작성하는 모든 방법을 테스트해야합니다. 기본 TBDD 도구를 따를 때 들리는 것보다 훨씬 간단합니다.

나는 어떻게 시험 하는가 에 대한 Ryan Bates의 Rails Cast 가 저에게 매우 귀중하다는 것을 알았고 올바르게 완료되면 TBDD의 단순성을 실제로 강조했습니다.

실제로 TDD 방법론을 사용하고 있다면 먼저 단위 테스트를 거치지 않고 코드를 작성하지 않아도됩니다.

TDD로 시작하지 말고 싶습니다. 일반적으로 아키텍처 전략을 배우는 데 더 많은 시간을 할애했을 때 충분한 정보를 바탕으로 결정하십시오. TDD는 그 숙제를 믿기 시작하더라도 그 숙제를 건너 뛸 수 없습니다.

여기 내 문제가 있습니다. 당신이 TDDers를 결코 깨뜨리지 않을 것들에 많은 시간을 낭비하는 것처럼 보일 때 TDDers는 거대한 의존성 체인에서 예상하지 못한 한 가지가 파열 될 때 감사 할 것이라고 말합니다. 앱을 작성하기 전에 그러한 것들을 예측하는 것이 불가능하다는 것을 지적하면, 우리가 테스트하는 이유는 테스트에 도움이 되더라도 실제로 디자인에 대한 것이지 테스트가 아니라고 말합니다.

그러나 예측할 수없는 연결 종속성의 거대한 체인은 크 래피 디자인의 산물이 아닌가?

그래서 어느 것입니까?

여기에 생각이 있습니다. 디자인 패턴에서 다음 두 가지 객체 지향 디자인 원칙을 고려하여 처음에는 거대한 복잡한 종속성 체인을 갖지 않겠습니다.

"구현이 아닌 인터페이스로의 프로그램"

다시 말해서, 당신의 사물은 누가 부르고 있는지 또는 어떻게 만들어 졌는지 신경 쓰지 않아야합니다. 적절한 인수가 제공되고 다른 객체에서 호출하는 메소드가 예상대로 작동하도록 지시 한 경우에만 해당됩니다. 대부분의 경우 의존성 체인은 하나의 연결 지점, 호출자 측의 메소드 호출 및 args가 메소드에 드롭되는 지점에 있어야합니다. 그곳에서 문제가 발생했을 때 디버그를 위해 유용한 메시지를 기록하고 확인하고 보낼 수 있습니다.

과:

"클래스 상속에 대한 선호 객체 구성"

더미는 누구입니까? 30 개의 클래스와 같은 복잡한 계단식 상속 체계에서 클래스에 무언가를 한 사람이 프린지 케이스가 파손되거나 처음에 그 아키텍처를 만든 개발자? TDD를 사용하면 피사 급 ​​피사의 사탑 내부의 문제를 가장 빨리 해결할 수 있지만 다음에 코드 재난의 종점 중 하나를 수정하려고 시도하는 것이 덜 고통 스럽습니까?

그리고 그것이 나를 괴롭히는 것에 도달하는 곳입니다. TDD가 설계에 실제로 도움이됩니까, 아니면 잘못된 아키텍처를 가능하게합니까? 자체 이행 전략이 될 가능성이있는 것 같습니다. 팀이 열악한 아키텍처에 대한 책임을 가질 필요가 없을수록 세분화 된 테스트 구성 요소가 더 도움이되는 것처럼 보이지만 궁극적으로 앱이 점점 더 큰 PITA가되어 아키텍처를 처음부터 아끼지 않았다고 가정합니다. 장소). 그리고 그 결과를 인정하지 않으면 시간이 지남에 따라 업그레이드되고 수정되는 응용 프로그램에서 작업 할 때 항상 가장 비싼 실수입니다.

질문에 대답하려면 "여기서 무엇이 잘못 될 수 있는가"에 대해 생각하십시오. 특히, "코드"(마크 업 / 무엇이든)를 변경하면 페이지가 손상되지 않았다는 확신을 갖게됩니다. 정적 페이지의 경우 :

• 렌더링되지 않을 수 있습니다
• 잘못 렌더링 될 수 있습니다
• JS가로드되지 않을 수 있습니다
• 이미지의 경로가 작동하지 않을 수 있습니다
• 링크가 끊어졌을 수 있습니다

개인적으로 다음을 권장합니다.

• 페이지에서 예상되는 하나의 문자열을 확인하는 셀레늄 [1] 테스트를 작성하십시오 (가능한 경우 하단 근처). 렌더링되는지 확인합니다.
• JS 오류가 없는지 확인하십시오 (셀레늄이 이것을 허용한다고 생각합니다)
• 정적 페이지를 html 유효성 검사기 및 가능한 경우 링크 검사기를 통해 실행하십시오.
• JS의 유효성을 검사하는 도구를 찾지 못했지만 jslint 또는 jshint에서 성공할 수 있습니다.

여기서 반복되는 것은 반복 가능하고 사용하기 쉽고 테스트 러너에서 자동으로 실행되는 것을 원한다는 것입니다.

이미 훌륭한 답변을 모두 추가하기 위해 테스트 할 것과 테스트하지 않을 것에 대한 나의 생각은 다음과 같습니다.

테스트하십시오 :

• 비즈니스 로직
• 응용 로직
• 기능성
• 행동,
• 따라서 실제로 다음을 제외한 모든 것이 있습니다 .

테스트하지 마십시오 :

• 상수
• 표시

따라서 다음과 같은 테스트가 필요하지 않습니다.

assert wibble = 3

그리고 일부 코드는

wibble = 3

또한 아이콘이 청록색인지, 제목에 사용한 글꼴 등과 같은 프리젠 테이션을 테스트 할 때는 아무런 의미가 없습니다.

따라서 "정적 페이지를 테스트해야합니까?"라고 물으면 대답은 다음과 같습니다. 사이트의 기능, 비즈니스 로직 또는 동작의 일부인 한 테스트합니다.

따라서 앱에는 익명의 사용자, 로그인 한 사용자, 대시 보드, 앱 화면 내부 등 사이트의 모든 부분에서 이용 약관을 확인할 수있는 테스트가 있습니다. 각 페이지에 "약관"이라는 링크가 있고 링크가 작동하고 테스트 결과 페이지에 도착하면 Ts & Cs처럼 보입니다. "상수 테스트"또는 "프레젠테이션 테스트"없이 ... 예를 들어 특정 글꼴 크기 나 텍스트 레이아웃을 확인하지 않고 텍스트가 올바른지 확인할 수 있습니다.