당신은 당신이 원하는 것을 알고 있습니다. 하지만 코드가 협력하지 않을 뿐입니다. 들여쓰기 수준이 너무 많거나 6가지 방법을 연결하거나 비대칭적으로 보일 수 있습니다. 뭐니뭐니해도 그냥 기분이 좋습니다. 무시해도 됩니다. 아직 작성하고 싶은 기능으로 가득 찬 백로그가 있지만 실제로는 그것이 아닙니다. 나쁜. 하지만 그것은 실수일 것입니다. 코드가 당신에게 무언가를 말하려고 하고 있으며, 당신은 그것을 놓치고 싶지 않습니다.
코드가 이상하다고 느낄 때를 구별하는 법을 배울 수 있다면 소프트웨어 설계 기술을 빠르고 크게 향상시킬 수 있습니다. . 이 직관은 경험, 멘토링 및 코드 검토에서 비롯되기 때문에 구축하기 어렵습니다. 그러나 구문 식초를 사용하여 나쁜 코드를 기분 나쁘게 만드는 라이브러리의 도움을 받을 수 있습니다.
구문 식초는 어떻게 생겼나요?
다음은 Ruby와 함께 제공되는 작은 조롱 및 스터빙 라이브러리인 minitest/mock을 사용하는 구문 식초의 예입니다.
require 'minitest/mock'
class CartTest < MiniTest::Test
def test_error_message_set_on_charge_failure
cart = Cart.new(items)
cart.stub(:charge!, false) do
cart.checkout!
assert_equal "The credit card could not be charged", cart.credit_card_error
end
end
end
테스트를 실행하면 charge!
Cart
의 메소드 스텁 처리되어 테스트가 결제 프로세서에 도달하지 않습니다. 블록 구문은 원할 때만 정확히 스텁하도록 하는 데 유용합니다. 하지만 여러 메서드를 스텁하고 싶을 때는 어떻게 됩니까?
require 'minitest/mock'
class CartTest < MiniTest::Test
def test_error_message_set_on_charge_failure
payment_processor = PaymentProcessor.new
cart = Cart.new(items, processor: payment_processor)
payment_processor.stub(:charge!, false) do
payment_processor.stub(:login!, true) do
payment_processor.stub(:logout!, true) do
cart.checkout!
assert_equal "The credit card could not be charged", cart.credit_card_error
end
end
end
end
end
어. 그것은 많은 들여 쓰기입니다. 이는 단일 테스트에 불과합니다. 이 코드가 다른 많은 테스트에서 반복되는 것을 상상할 수 있습니다.
할 수 있습니다 이 모든 중첩을 테스트 도우미 메서드로 래핑합니다. 하지만 정말 코드를 들으면 더 나은 방법을 찾아야 한다고 말합니다. 대신 Test Double을 사용하는 방법을 살펴봐야 할 때입니다.
class TestPaymentProcessor < PaymentProcessor
def login!(account_id, key)
true
end
def charge!(amount, credit_card)
credit_card.can_be_charged?
end
def logout!
true
end
end
class CartTest < MiniTest::Test
def test_error_message_set_on_charge_failure
test_payment_processor = TestPaymentProcessor.new
cart = Cart.new(items, processor: test_payment_processor)
cart.credit_card = failing_credit_card
cart.checkout!
assert_equal "The credit card could not be charged", cart.credit_card_error
end
end
이제 테스트가 더 읽기 쉽습니다. 또한 TestPaymentProcessor
가 있습니다. 다른 많은 곳에서 사용할 수 있습니다. 실제 서버에 접속하고 싶지 않다면 개발 모드에서 사용할 수도 있습니다!
나쁜 코드는 기분이 나빠야 합니다.
나쁜 코드를 명백하게 만드는 독선적인 라이브러리를 사용하면 나쁜 코드를 훨씬 빠르고 안정적으로 알아차리기 시작할 것입니다. 그러면 미래의 코드가 더 깔끔하고 읽기 쉬우며 작업하기가 덜 힘들 것입니다.
당신이 가장 좋아하는 독선적인 라이브러리는 무엇이며, 나쁜 코드를 찾고 수정하는 데 어떻게 도움이 됩니까? 아래 댓글로 알려주세요!