미친 루비 테스트

몇 주 전에 트위터에 이런 글이 올라왔습니다.

when you think you've seen everything in Ruby pic.twitter.com/6Q7m9kOcwV

— Konrad Oleksiuk (@koleksiuk)

그 코드 조각을 읽은 직후 내 마음에는 영리함과 사악함이라는 두 가지 대조적인 생각이 떠올랐습니다.

그것에 대한 내 마음 상태를 나타내는 올바른 용어는 숭고합니다.

The Sublime (from the Latin sublimis, or in the variant sublimus, composed of sub-, "below", and limen, "threshold"; therefore properly: "what is at the limit", or of sub-, "below" , and limen-, "threshold", properly "that reaches below the highest threshold") is an aesthetic category that dates back to classical antiquity and later to Romanticism.

(출처: Wikipedia )

😎 이것에 대해 영리한 점은 무엇입니까?

Ruby 메타프로그래밍의 강력함과 보급성입니다. Ruby의 모든 것, 또한 언어의 단순한 "문장"으로 나타날 수 있는 것은 실제로는 메서드 호출(+괄호를 선택적으로 만드는 구문 설탕)입니다.

공개 방법을 테스트하는 것만큼 쉽게 개인 방법을 테스트할 수 있습니다. 간단한 예를 들어 설명해 보겠습니다.

class MyClass
  attr_accessor :object_id
  ...
  # some public methods
  ...

  private

  def object
    @object ||= object_class.find_by(id: object_id)
  end
end

object에서 비공개 메서드MyClass를 어떻게 테스트하시겠습니까?
그 트릭이 없으면 네 가지 선택이 있습니다.

테스트해야 하는 비공개 메서드를 공개합니다.
물론 이 선택은 의미가 없습니다. 공개(=클라이언트가 사용할 수 있는 것으로 간주되어야 함)와 그렇지 않은 것에 대한 API 설계는 테스트 제약 조건에 의해 조건이 지정되어서는 안 됩니다.

개인 메서드를 테스트하지 마십시오. 누군가 괜찮다는 데 동의할 수 있습니다. 저는 그렇지 않으며 다음 단락에서 그 이유를 설명하겠습니다.

루비의 메시지 전달 기능을 이용하세요:

require 'test_helper'

class MyClassTest
  let!(:obj) { AClass.create }
  let(:subject) { MyClass.new }

  def test_object
    subject.stubs(:object_class).returns(AClass)

    assert_equal obj, subject.send(:object) # this sounds quite "awkward"...
  end
end

😈 이것에 대해 무엇이 잘못(악)합니까?

코드와 TDD의 순수주의자가 손가락을 뻗을 수 있는 위치에 대한 질문은 다음과 같습니다.

Shall I really test private methods?

훌륭한 Steven Solomon( )은 개인용 메서드를 테스트하는 올바른 방법으로 간주되어야 하는 것에 대한 글excellent post을 작성했으며 저도 그에 동의합니다.
따라서 여기에서 제 의도는 동일한 고려 사항을 다시 작성하는 것이 아니라 한 가지 간단한 사실에 대한 개인적인 관점을 추가하는 것입니다. 위에서 작성한 것처럼 테스트(특히 레거시 코드)는 드물게 좋은 코드 설계를 향한 경로입니다.
물론 올바른 TDD를 수행하고 있다면 먼저 코드를 작성하면 코드가 제공하는 소위 "신흥 디자인"의 아름다움을 즐길 수 있으며 개인 메서드를 직접 테스트할 필요가 없을 것입니다.

하지만

레거시 코드를 매일 처리하는 경우 최적의 솔루션과 제대로 작동하는 솔루션 사이에서 타협해야 하는 경우가 많습니다.
이러한 선택에서 코드를 공개하지 않은 상태로 유지함으로써 잘못된 원래 설계 결정을 내리면 코드베이스를 언젠가 청구서를 제시할 기술적 부채의 무덤 속으로 더 깊이 파고들 것입니다.
다른 한편으로 전체 "스파게티 코드"머드를 한 번에 완전히 리팩토링하는 데 드는 비용은 직면하기가 너무 어려울 수 있으며 다음과 같은 유혹을 받을 수 있습니다. 언젠가". 즉, 절대로.

그래서 뭐?

사용할까 말까?

여기서 우리는 소프트웨어 디자인의 패턴과 반패턴에 대한 의견의 땅에 왔습니다.

이 경우에는 확실한 진실이 없다고 생각합니다.

완벽함은 asymptote입니다. 그것이 어디에 있는지 알고 있고 목표가 될 수 있지만 결코 도달할 수 없다는 것을 알고 있습니다(그래도 괜찮다고 생각합니다).
또한 그것은 작은 발걸음으로 만들어진 길입니다. 우리는 절망과 체념의 구렁에 빠지지 않고 매일 한 걸음 더 나아가는 방식으로 접근해야 합니다.

내 작은 도시인 볼로냐에는 영어로 번역하기 어려운 속담이 있습니다.

Rather than nothing, it's worth "rather"...

또는 다른 말로 표현하자면, 무언가를 향상시키기 위해 무엇을 하든지 아무것도 하지 않는 것보다 낫습니다.

나는 완벽을 향한 우리의 길에서 언젠가는 그 코드를 되돌아보며 이렇게 생각하게 될 것이라고 생각합니다.

당신이 이미 알고 있는 글을 쓴 것에 대해 지금 당신 자신을 비난하지 마세요. 언젠가 미래에 (아마도 그리고 희망적으로) 비난받을 것입니다: 그날은 좋은 날이 될 것입니다. 당신은 개발자로서 성장할 것이고 당신은 , 작고 나쁘고 유용한 단계를 먼저 수행하지 않은 경우.