Ruby의 커널 클래스에 assert () 메소드를 추가하는 것이 관용적 인 루비입니까?

StackOverflow https://stackoverflow.com/questions/147969

  •  02-07-2019
  •  | 
  •  

문제

루비에서 켄트 벡의 Xunit과 동등한 것을 코딩하여 루비 이해를 확장하고 있습니다. Python (Kent가 쓰는)은 광범위하게 사용되는 언어로 assert () 메소드를 가지고 있습니다. 루비는 그렇지 않습니다. 나는 이것을 추가하기가 쉽지만 커널을 넣을 수있는 올바른 장소입니까?

btw, 나는 루비의 다양한 단위 프레임 워크의 존재를 알고 있습니다. - 이것은 "무언가를 끝내기"보다는 루비 관용구를 배우는 운동입니다.

도움이 되었습니까?

해결책

아니오는 모범 사례가 아닙니다. Ruby의 Assert ()와 가장 유사한 것은 단지 올리는 것입니다.

 raise "This is wrong" unless expr

보다 구체적인 예외 처리를 제공하려면 자신의 예외를 구현할 수 있습니다.

다른 팁

루비에서 어설 션을 사용하는 것이 완전히 유효하다고 생각합니다. 그러나 당신은 두 가지 다른 것을 언급하고 있습니다.

  • xunit 프레임 워크 사용 assert 시험 기대치를 확인하는 방법. 응용 프로그램 코드가 아닌 테스트 코드에서 사용되도록 의도됩니다.
  • C, Java 또는 Python과 같은 일부 언어에는 assert 시공은 프로그램 코드 내부에서 사용되어 무결성에 대한 가정을 확인하기 위해 사용되었습니다. 이 검사는 코드 자체 내부에서 구축됩니다. 그들은 테스트 시간 유틸리티가 아니라 개발 시간입니다.

나는 최근에 썼다 solid_assert : 루비 어설 션 유틸리티를 구현하는 작은 루비 도서관 그리고 또한 내 블로그의 동기를 설명하는 게시물.. 형식으로 표현식을 쓸 수 있습니다.

assert some_string != "some value"
assert clients.empty?, "Isn't the clients list empty?"

invariant "Lists with different sizes?" do
    one_variable = calculate_some_value
    other_variable = calculate_some_other_value
    one_variable > other_variable
end

그리고 그들은 비활성화 될 수 있습니다 assert 그리고 invariant 빈 진술로 평가하십시오. 이를 통해 생산의 성능 문제를 피할 수 있습니다. 그러나 그것을 주목하십시오 실용적인 프로그래머 그들을 비활성화하는 것을 권장하십시오. 성능에 실제로 영향을 미치는 경우에만 비활성화해야합니다.

관용적 루비 방식이 정상을 사용하고 있다고 말하는 대답에 관해 raise 진술, 나는 그것이 표현력이 부족하다고 생각합니다. 독단적 프로그래밍의 황금 규칙 중 하나는 정상적인 예외 처리에 어설 션을 사용하지 않는 것입니다. 그들은 완전히 다른 두 가지입니다. 두 가지에 대해 동일한 구문을 사용하면 코드가 더 모호하다고 생각합니다. 물론 당신은 그들을 비활성화 할 수있는 능력을 잃습니다.

당신은 어설 션을 사용하는 것이 좋은 것이라고 확신 할 수 있습니다. Journeyman에서 Master까지 실용적인 프로그래머 그리고 코드 완료 전체 섹션을 그들에게 전념하고 사용 권장입니다. 좋은 기사도 있습니다 어설 션으로 프로그래밍 그것은 단호한 프로그래밍에 관한 것과 그것을 사용하는시기를 잘 보여줍니다 (Java에 기반을두고 있지만 개념은 모든 언어에 적용됨).

Assert 메소드를 커널 모듈에 추가 한 이유는 무엇입니까? 호출 된 다른 모듈 만 사용하지 않겠습니까? Assertions 또는 뭔가?

이와 같이:

module Assertions
  def assert(param)
    # do something with param
  end

  # define more assertions here
end

당신이 실제로 당신의 주장을 사용할 수 있도록해야한다면 어디에나 다음과 같이하십시오 :

class Object
  include Assertions
end

면책 조항 : 코드를 테스트하지는 않았지만 원칙적으로는 이렇게 할 것입니다.

특히 관용적이지는 않지만 좋은 생각이라고 생각합니다. 특히 다음과 같이 완료 한 경우 :

def assert(msg=nil)
    if DEBUG
        raise msg || "Assertion failed!" unless yield
    end
end

이렇게하면 디버그로 실행하지 않기로 결정한 경우 (또는 다른 편리한 스위치가 과거에 Kernel.do_assert를 사용했습니다) 세트에 영향을 미치지 않습니다.

내 이해는 루비에 더 익숙해지는 방법으로 자신의 테스트 스위트를 작성한다는 것입니다. 따라서 Test :: 장치는 가이드로 유용 할 수 있지만 아마도 당신이 찾고있는 것이 아닐 수도 있습니다 (이미 작업을 수행했기 때문에).

즉, Python의 주장은 (적어도 나에게) C의 말과 더 유사합니다. 주장 (3). 그것은 단위 테스트를 위해 특별히 설계된 것이 아니라 "이것이 결코 일어나지 말아야 할"사례를 포착하도록 설계되었습니다.

루비의 내장 단위 테스트가 문제를 보는 경향이있는 방법은 각 개별 테스트 사례 클래스가 서브 클래스라는 것입니다. 테스트 케이스, 그리고 여기에는 전달 된 내용의 유효성을 확인하고보고를 위해 기록하는 "Assert"진술이 포함됩니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top