약간의 RSpec(t)

인트로

몇 가지 방법으로 코드를 테스트할 수 있습니다. 우리는 일반적으로 byebug와 같은 디버깅 도구를 사용하여 사물이 제대로 작동하는지(또는 작동하지 않을 때...) 확인하기를 원합니다. 잘 배치된puts만 있으면 코드의 특정 지점에서 무슨 일이 일어나고 있는지 확인할 수 있습니다. 콘솔을 사용하여 메서드를 테스트할 수 있습니다. 그들에게 작업할 데이터를 제공하고 우리가 그 대가로 무엇을 받는지 확인합니다.
그러나 적절한 테스트를 위해 테스트 프레임워크(또는 제품군)를 사용합니다.
테스트 프레임워크를 사용하면 코드를 실행하고 결과가 예상대로인지 확인할 외부 파일을 작성할 수 있습니다.
Ruby on Rails는 자체 테스트 프레임워크와 함께 제공되지만 이 블로그에서는 RSpec을 사용하는 방법에 대해 논의할 것입니다.

자체 테스트 작성

우리가 작성한 코드가 예상대로 작동하는지 확인하기 위해 테스트를 작성하는 대신 TDD에서는 구현된 코드를 작성하기 전에 테스트를 작성하는 것이 관행입니다.

이 개발 관행은 우리가 달성하려는 것이 무엇인지, 그리고 그것을 어떻게 구축할 것인지에 대해 멈추고 생각하게 합니다.
바로 구현에 뛰어들면 코드에서 정확히 무엇을 기대해야 하는지 간과할 수 있습니다.
이로 인해 불필요한 코드를 작성하는 데 많은 시간을 낭비하게 됩니다.

우선, 다음을 수행할 수 있습니다.

달성하려는 것과 일치하는 테스트를 작성하십시오.

테스트를 실행합니다(아직 코드를 작성하지 않았으므로 실패합니다).

테스트를 통과하도록 코드를 작성하는 방법을 생각해 보십시오.

코드를 작성하고 테스트합니다.

모든 테스트를 통과할 때까지 4단계를 반복합니다

.

코드를 리팩터링하고 여전히 테스트를 통과하는지 확인합니다.

이 프로세스를 고수하면 목표를 정확히 달성하고 정확하고 의미 있는 코드를 작성하고 모든 것이 올인원으로 작동하는지 확인할 수 있습니다.

BDD(행동 중심 개발)는 TDD에서 한 단계 발전된 것입니다.
차이점에 대해서는 많이 다루지 않겠습니다. 그러나 BDD는 최종 사용자의 관점에서 테스트되고 준비할 팀(관리자 및 테스트 엔지니어 포함)이 필요하며 BDD는 작은 코드 조각이 아니라 기능을 테스트한다고 말하는 것으로 충분합니다.

RSpec

프로세스는 충분히 간단하지만 프로젝트에서 RSpec을 설정하는 방법에 대해서는 다루지 않을 것입니다.

RSpec에서는 애플리케이션 동작에 대한 사양(사양)이기도 한 테스트를 작성합니다.describe 키워드를 사용하여 테스트 블록을 정의합니다.
그런 다음 예상되는 동작을 설명합니다.
테스트는 클래스 이름(기존 클래스의) 또는 문자열을 허용합니다.

계산기 앱에 대한 테스트를 작성한다고 가정해 보겠습니다.
숫자의 지수 결과(x**y = 결과)를 계산하도록 설계된 ".exponent_calculator"라는 클래스 메서드가 있습니다.

describe Calculator do

  describe ".exponent_calculator" do
    context "given two numbers" do
      it "returns a result of the first number raised to the power of the second number" do
        expect(Calculator.exponent_calculator(2,10)).to eq(1024)
      end
    end
  end
end

우리는 평범한 영어로 방법에 대해 기대되는 것과 어떤 맥락에서 설명하고 있습니다(문맥은 선택 사항입니다).
이를 통해 테스트를 이해하고 유지하기가 매우 쉽습니다.
실행rspec은 그런 다음 메서드에 숫자 2와 10을 보내면 1024가 반환되는지 확인합니다. 테스트는 결과에 따라 통과 또는 실패합니다.
더 나은 테스트를 위해 엣지 케이스도 테스트하고 싶을 것입니다.
가능한 모든 입력을 고려하십시오(2차 방정식 계산기를 테스트한다고 상상해 보십시오. 또는 직접 빌드하고 테스트하는 것이 좋습니다. 꽤 재미있습니다.)

구현된 코드를 작성할 때 의도적으로 테스트에 실패하면 어떤 일이 발생하는지 확인하십시오. 실제로 필요할 때만 통과하는지 확인하십시오.

결론

테스트에 대해 다루어야 할 것이 훨씬 더 많습니다. 테스트는 경력 경로가 될 수도 있습니다. 이것은 테스트가 무엇인지에 대한 작은 맛보기였습니다. 좋든 싫든 결국 테스트는 개발의 큰 부분입니다. TDD와 BDD는 어떤 식으로든 여러분의 삶의 일부가 될 것입니다.

참조

rspec GitHub page
A nice beginner's tutorial I found
BDD vs TDD