단위 테스트를 더 즐겁게 만들었습니까? [닫은]

당신이 항상 단위 테스트를 좋아한다면, 당신에게 좋습니다! 그러나 마음에 들지 않은 채 태어나지 않은 불행한 사람들에게는 어떻게이 일을 더 즐겁게 해 주었습니까?

이것은 "단위 테스트를위한 올바른 방법"이 아닙니다. 나는 단순히 단위 테스트 작성의 지루함을 줄여주는 약간의 개인적인 트릭을 알고 싶습니다.

먼저, 나는 당신에 동의합니다-당신이 이미 완성 된 코드에 대한 단위 테스트를 작성하거나 수동으로 코드를 단위 테스트하는 경우, 그것은 매우 지루합니다.

실제로 즐겁게 사용할 수있는 두 가지 단위 테스트 방법이 있습니다.

1. TDD (Test Driven Development)를 사용하여 먼저 테스트를 작성하면 코드에서 필요한 다음 기능 또는 동작에 대해 생각할 수 있습니다. 나는 작은 걸음으로 최종 목표를 향해 운전하고 몇 분마다 그 목표를 향한 실질적인 진전을 매우 보람 있고 즐겁게 본다.
2. 디버거로 곧장가는 것이 아니라 버그가있을 경우, 버그를 재현하는 실패한 단위 테스트를 작성하는 방법을 알아내는 것은 어려운 도전입니다. 코드가 실패하는 상황을 파악한 다음 수정하여 새로운 실패한 테스트에 대해 막대가 녹색으로 바뀌는 것을 확인하고 기존의 모든 테스트에 대해 녹색을 유지하는 것은 매우 만족 스럽습니다.

잘난 척하는 우월.

나는 단지 반 농담입니다. "좋은 프로그래밍 습관을 키우는 저를보세요!이 '단위 테스팅'은 10 년 전부터 제가 해 본 적이 없었던 일입니다. 어리석은 일입니다! 그리고 내가 겪은 모든 버그를 생각해보십시오. 내가 지금하고있는이 지루하고 지루한 작업 – 내 코드는 훌륭 할 것입니다! 확실히 인상 할 것입니다! * "

*-아뇨.

나는 그것이 운동을하거나 건강을 먹는 것과 같다는 것을 안다. 실질적인 혜택이 실제로 시작될 때까지 ( "거룩한 공, 나는 생산에 몰려 들었던 엄청난 회귀 오류를 포착하고있다!"), 올바른 일을하고 있다는 것을 아는 도덕적 자부심은 당신을 도울 수 있습니다 을 통하여.

하나, 나는 거의 거기에 앉아서 단위 테스트를 작성하지 않습니다. 단위 테스트는 목적이 아니라 목적을위한 수단입니다. "이 코드는 기본 작업을 수행합니까?"라고 대답하는 방법입니다.

예를 들어, 어떤 사람들은 함수를 작성한 다음 대화식 세션을 열어 몇 가지 값으로 테스트하고 작동하는지 확인합니다.

def fact x
  if x == 0
    1
  else 
    x * fact(x-1)
  end
end

>> fact 10
=> 3628800
>> fact 7
=> 5040

그러나 이제 버그를 발견했습니다.

>> fact -1
SystemStackError: stack level too deep
    from (irb):2:in `fact'
    from (irb):5:in `fact'
    from (irb):10

그래서 당신은 그것을 고칩니다 :

def fact x
  if x < 0
    raise "Can't take the factorial of a negative number"
  elsif x == 0
    1
  else 
    x * fact(x-1)
  end
end

>> fact -1
RuntimeError: Can't take the factorial of a negative number
    from (irb):3:in `fact'
    from (irb):10

그러나 이제는 여전히 작동하는지 테스트해야합니다.

>> fact 10
=> 3628800
>> fact 7
=> 5040

보시다시피, 동일한 테스트를 계속 반복하고 결과를 시각적으로 비교해야합니다. 이 경우 단위 테스트는 반복을 피하는 방법입니다. 필요한 작업량을 줄입니다. 그리고 이것은 실제적으로 어리석은 작은 예이지만, 점점 더 중요 해지고 수동 테스트는 점점 더 어려워지고 있습니다. 물론 이것이 의미하는 바는 사람들이 단순히 개별 구성 요소를 테스트하지 않는다는 것입니다. 그들은 단지 전체 프로그램을 테스트합니다. 그러나 버그가 발생하면 찾기가 훨씬 어렵습니다. 또는 버그가 발생하고 수정되었지만 누군가가 동일한 버그를 다시 소개합니다. 아무도 테스트 케이스를 추가하지 않았기 때문입니다. 또는 누군가 큰 코드를보고 "문서화되지 않았으며 테스트를 수행하지 않았기 때문에 어떻게해야할지 모르겠습니다 ... 이 버그를 고치면 그에 따라 다른 것을 깰지 모른다. 아마 나는 이것을 처음부터 다시 쓸 것이다. "

이 경우 단위 테스트는 추가 작업을 모두 줄입니다. 그것들을 재미있게 만드는 가장 좋은 방법은 사람들이 교체하는 모든 작업을 이해하고 각 코드 조각이 무엇을해야하는지 아는 추가적인 유연성을 이해하는 것입니다. 어느 정도 사람들은 단위 테스트가 얼마나 중요한지 이해하기 위해 큰 코드 기반을 작성하고 유지 관리하는 데 약간의 경험이 필요합니다. 모든 코드가 한 번 작성하여 버린다면 절대로 얻지 못할 것입니다.

"알고"이미 작동하는 코드가 있으면 추가 작업으로 단위 테스트를 작성해서는 안됩니다. 단위 테스트는 먼저 작성하거나 문제의 코드를 작성한 직후에 작성해야합니다. 이를 테스트 중심 개발이라고하며 API를 개선하는 데 도움이 될 수 있습니다. API를 먼저 실행하는 테스트를 작성하는 경우 코드를 작성하기 전에 API가 사용하기 어려운 부분을 배우고 나중에 테스트를 추가하는 것보다 훨씬 쉽게 재 설계 할 수 있습니다.

모르겠어요 단위 테스트를 더 즐겁게 만드는 것은 소프트웨어를 변경할 때마다 겪지 않을 모든 좌절, 길고 지루하고 보상이없는 디버깅에 대한 생각입니다. :)

견고하고 견고하며 안정적인 코드를 체크인 할 때 느끼는 대단한 우수성. 코드 커버리지 도구를 사용하여 단위 테스트를 작성하는 경우 코드 커버리지가 90 % 이상이라는 주석을 확인할 수 있습니다.

분명히, 테스트 우선 개발의 만족도와 디자인과 테스트가 결합 될 때 느끼는 느낌이 있습니다. 그러나 기존 / 레거시 코드에 대한 테스트를 작성하는 것은 많은 비용이 들고 실망 스러울 수 있습니다. 프로젝트가 유지 보수 패턴에 있었을 때, 커버리지 보고서를 게임으로 사용하여 테스트되지 않은 코드에 대한 테스트를 작성했습니다. 귀하 및 / 또는 다른 사람들과 약간의 경쟁을 일으켜 적용 범위를 넓힐 수 있습니다. 물론, 당신은 그것을 너무 멀리 가져 와서 나쁜 테스트를 만들 수 있지만, 좋은 동기 부여가 될 수 있습니다.

흐름에 들어가보십시오 . 힘들지만 달성 가능한 목표를 스스로 설정하십시오. 단위 테스트의 목표는 무엇입니까? 예를 들어, 품질을 유지하면서 더 빨리 쓰십시오. 단위 테스트에는 너무 많은 생각이 필요하지 않으므로 착각이 거의 없습니다. 목표에 집중하고 가까이 다가가는 것을 자주 확인하십시오.

때로는 동기 부여를 위해 하루의 시작 부분에 현재 "코드 적용 범위"를 기록합니다. 그런 다음 테스트를 작성하여 통과 할 때마다 제품군을 실행하고 적용 범위 번호를 업데이트합니다. 재미 있고 왜 내가이 일을하는지 상기시켜줍니다. (다른 이유도 있지만 숫자가 마음에 듭니다. 어쩌면 저뿐입니다!)

자신을 속이려고하지 않음으로써 단위 테스트를 지속 가능한 기간 동안 즐길 수 있다고 생각하도록 속일 수 있습니다.

단위 테스트가 즐기지 않는다는 현실을 받아들이면 큰 도움이되며, 절대로 예상치 못한 곳에서 무언가를 찾고 있다는 것을 깨닫게됩니다.

이 간단한 정신 여행에서 유닛 테스트가 실제로 무엇인지를 인식 할 때, 즉 잔인하고 견딜 수 없으며 영혼을 짓밟는 지루한 일이 될 때 나는 스스로를 놓아 줄 여유가 있는지 스스로에게 묻습니다. 기능적 정확성을 보장합니다.

항상 대답은 "아니오"입니다.

운명을 받아 들일 때, 나는이 사각형 물체를 문자, 숫자 및 기호로 내 앞에 밀어 넣습니다. 키보드를 부르는 첫 경험에서 각 키보드 클릭으로 단위 테스트의 끝이 더 가깝다는 것을 알고 있습니다. 한 적 있었다.