나는 단위 테스트를 공부하고 코드에 적용하려고했지만 동료들과 이야기를 나눈 후 그 중 일부는 필요하지 않으며 이점이 거의 없다고 제안했다. 또한 실제로는 소수의 회사 만이 생산 소프트웨어로 단위 테스트를 수행한다고 주장합니다.
사람들이 직장에서 단위 테스트를 어떻게 적용했으며 코드 품질 향상, 장기 개발 시간 단축 등과 같은 이점을 통해 얻는 이점이 궁금합니다.
답변
그들 중 일부는 필요하지 않다고 제안합니다.
엄밀히 말하면 테스트, 코드 검토, 소스 제어 등이 꼭 필요한 것은 아닙니다 . 현명한 개발자들만이 장기적으로 이러한 작업없이 작업 할 수 있습니다. 우리 대부분은 왜 이것이 모범 사례인지를 배웠습니다.
이점이 거의 없습니다.
대부분의 경우 사실 이 아닙니다 . 즉, 향후 몇 년 동안 사용 중이 어서 유지 관리에 사용되는 프로덕션 소프트웨어에 대해 이야기하고 있다면 말입니다.
또한 생산 소프트웨어로 단위 테스트를 수행하는 회사는 거의 없다고 주장합니다.
이것은 사실 일 수도 있지만 (내 경험상 그 정도는 적지 만) 단위 테스트 의 가치 에 대해서는 말할 것도 없습니다 . 이것과는 달리 오래된 농담은 “새끼가 좋다-500 억 파리는 틀릴 수 없다!” 😉
직장에서 단위 테스트를 적용했으며 그로부터 무엇을 얻습니까? (예 : 코드 품질 향상, 장기적인 시간 단축 등)
나는 가능할 때마다 10 년 넘게 작업에 단위 테스트를 적용 해 왔습니다. 내 코드에 대한 자신감의 느낌, 그것이 작동한다는 것을 알고 있으며, 단지 그것을 믿는 것과는 달리 언제 어디서나 몇 초 만에 그것을 증명할 수 있습니다 . 기존 기능을 중단 할 염려없이 코드를 리팩토링하고, 디자인을 개선하거나, 버그를 수정하는 용기가 생겼습니다. 나는 “코드와기도”의 옛날로 돌아 가지 않을 것입니다.
답변
나는 단위 테스트를 수행하지만 직장에서 (또는 거의)하지 않습니다.
내가 얻는 테스트의 주요 이점은 리팩토링이 훨씬 쉬우 며 회귀 (즉, 이미 수정 된 오류의 재 도입)가 발견된다는 것입니다.
테스트는 ‘빌드’로 진행됩니다. 테스트를 실행하여 소프트웨어를 체크 아웃하고 모든 테스트가 수정 된 상태로 실행될 때까지 체크인하지 않습니다.
내 경험에 따르면, 고독한 늑대의 방식으로 시험을 작성하는 것은 거의 쓸모가 없습니다. 다른 사람들이 변경 한 내용을 수용하기 위해 항상 테스트를 수정해야하는 경우, 동료가 테스트를 삭제할 수있는 경우 (이전 작업에서 발생했을 수 있음) ‘배포 할 수 없음’등은 추가 작업 일뿐입니다. 팀의 나머지 사람들이 즉시 얻는 혜택.
팀 전체가 동의하면 (그리고 쉬운 팀 1 명), 내 경험상 테스트는 프로젝트의 품질, 스타일 및 견고성에 큰 이점이됩니다.
그러나 정직하게“몇몇 회사 만이 코드를 자동으로 테스트합니다 ”라고 믿고 어쨌든 시간 낭비라고 확신하는 팀에서는 이점을 얻을 수있는 희망이 적지 만 큰 가능성이 있습니다. 오류를 지적 할 때 ‘시간 손실’에 대한 책임.
테스트를 도입 할 수있는 가장 좋은 기회는 전적으로 귀하의 책임 내 작은 프로젝트 일 것입니다. 거기서 당신은 시험의 가치를 빛나고 보여줄 수있는 기회를 갖게 될 것입니다.
답변
나는 동료들과 편견을 가지고 있지만, 한 시점까지만합니다.
단위 테스트와 관련된 문제는 코드에 대한 철저한 조사로 코드가 아무리 작동하더라도 밝혀지는 사소한 경우에 자주 그리고 무의식적으로 작성된다는 것입니다. 예를 들어 :
def add(x, y)
x + y
end
추가가 실제로 선택된 유스 케이스에 실제로 작동하는지 확인하기위한 수십 가지 테스트와 함께. 어 …
단위 테스트의 일반적인 전제는 다음과 같습니다. 코드에 버그가없는 경우 테스트가 충분하지 않기 때문입니다. 이제 적절한 단위 테스트를 작성해야합니다. 답변:
- 테스트 할 때
- 디버깅 할 때
- 정말 까다로운 것을 개발하면서
웹 앱을 개발하고 있다고 가정 해 보자.
새로운 기능에 일부 코드를 작성하면 이제는 합리적으로 잘 작동합니다. 그런 다음 브라우저를 찾아 더 집중적으로 테스트하여 브라우저가 작동하는지 확인하십시오. Bzzzt! … 오답. 단위 테스트를 작성합니다. 지금 그렇게하지 않으면 아마 결코하지 않을 것입니다. 그리고 이것은 단위 테스트가 잘 수행되는 곳 중 하나입니다. 높은 수준의 기능을 테스트하는 것입니다.
그런 다음 버그를 발견합니다 (누군가를 놓치지 않습니까?). 이것은 우리에게 두 가지를 지적합니다. 코드로 돌아가서 다음 단계를 따르십시오. 일관되고 정확한 데이터를 확보하는 것이 중요한 주요 중단 점에서 단위 테스트를 작성하십시오.
마지막 요점은 다른 길입니다. 많은 메타 프로그래밍이 필요한 일부 기능을 설계하고 있습니다. 수천 개의 잠재적 시나리오가 포함 된 의사 결정 트리를 신속하게 생성하며, 각각의 마지막 시나리오가 모두 작동하는지 확인해야합니다. 그러한 것들을 쓸 때, 여기 또는 간단한 변화는 먹이 사슬 아래로 상상할 수없는 결과를 가져올 수 있습니다. 예를 들어 SQL 트리거를 사용하여 MPTT 구현을 설계하여 여러 행 명령문으로 작업 할 수 있습니다.
이런 종류의 험한 환경에서는 일반적으로 테스트를 고도로 자동화하고 싶을 것입니다. 따라서 테스트 데이터 생성을 자동화하는 스크립트를 작성하고이 테스트 데이터에 대해 단위 테스트의 보트로드를 실행하십시오. 이렇게 할 때 추적해야 할 중요한 사항은 단위 테스트 생성기의 단위 테스트도 작성해야한다는 것입니다.
결론 : 단위 테스트, 물론 그렇습니다. 그러나 디버깅에 실제로 필요하거나 털이 많은 기능 (후자의 경우 테스트 자체 포함)이 제대로 작동하는지 확인하기 전까지는 기본 기능을 사용하십시오.
답변
모든 코드를 테스트해야합니다. 그것에 대한 선택의 여지가 없습니다.
테스트되지 않은 코드는 쓸모가 없습니다. 아무것도 할 수 없습니다.
단위 테스트를 작성하거나 더 높은 수준의 통합 테스트 또는 승인 테스트를 작성할 수 있습니다.
단위 테스트는 작성, 디버깅 및 관리가 더 쉽습니다.
통합 테스트는 장치가 실제로 작동한다는 가정을 기반으로합니다. 단위 테스트가 없으면 단위가 어떻게 작동하는지 어떻게 알 수 있습니까? 통합되는 개별 장치가 실제로 작동하는지 모르는 경우 통합 테스트를 어떻게 디버그 할 수 있습니까?
마찬가지로 합격 시험은 모든 부품과 부품에 따라 다릅니다. 일련의 단위 테스트없이 부품과 부품이 어떻게 작동하는지 알 수 있습니까?
테스트는 필수입니다. 모든 상위 레벨 테스트는 실제로 작동하는 장치에 따라 다릅니다.
따라서 단위 테스트가 논리적으로 필요합니다. 다른 선택은 없습니다.
답변
나는 내가 쓰는 모든 것에 대해 단위 테스트를 사용하며 테스트되지 않은 코드는 테스트 케이스없이 검토를 통과시키지 않습니다. (그러나 커버리지 도구가 없기 때문에 테스트 커버리지에 대해 추론해야합니다. 한 번에 한 가지 …)
그것은 매우 간단합니다 : 코드가 작동한다는 것을 증명할 수 없다면 (그리고 테스트 형태의 실행 가능한 사양보다 나은 방법은 무엇입니까?) 작동하지 않습니다 .
이것은 나에게 준다 :
- 안심 : CI 서버는 전체 코드베이스 작업을 알려줍니다.
- 내 코드를 개선하는 기능 : 재구성 한 후에는 아무 것도 깨지지 않았다는 것을 알면서 코드를 재구성 (리팩터링) 할 수 있습니다.
답변
단위 테스트는 학문입니다. 코드가 작동하지 않아도되므로 종종 폐기됩니다.
그러나 강력하고 버그가 적은 코드로 연결되는 입증 된 방법입니다. 당신이 이미 언급했듯이, 나는 당신에게 혜택을 설명 할 필요가 없다고 생각합니다. 자바 스크립트 라이브러리, 풀 스택 프레임 워크 또는 단일 목적 응용 프로그램 등 주요 오픈 소스 프로젝트를 살펴보면 모두 단위 테스트를 사용합니다.
나는 그것을 사용하지 말 것을 권장하는 동료가 프로그래머가 아니라고 생각합니다. 만약 그렇다면 Martin Fowler 나 Kent Beck 같은 사람들보다 내가 더 중요하게 생각하는 사람들이 많지 않다고 가정 해 봅시다 .).
대부분의 모범 사례와 마찬가지로 혜택은 장기적이므로 시간을 투자해야합니다. 절차 코드의 긴 스크립트를 작성할 수는 있지만 2 년 후에 리팩토링해야 할 때 객체 지향 스타일로 작성했으면합니다.
단위 테스트도 마찬가지입니다. 응용 프로그램에서 중요한 부분에 대한 단위 테스트를 작성하면 코드를 리팩토링 한 후에도 항상 의도 한대로 작동하는지 확인할 수 있습니다. 아마도 당신은 회귀 버그가 전혀 없도록 코딩을 잘합니다. 그러나 그렇지 않거나 새로운 프로그래머가 팀에 합류하면 과거의 버그가 다시 발생하지 않도록해야합니다. 반 년 전에 해결 된 것으로 생각되는 버그 보고서를 제출하는 것이 아니라 상사가 그 점에 만족할 것이라고 생각합니다.
답변
단위 테스트는 단위 테스트 친화적 언어, 단위 테스트 친화적 인 디자인 및 단위 테스트 친화적 인 문제가 필요합니다.
C ++, 멀티 스레드 디자인 및 GUI는 악몽이 될 것이며, 문제 범위는 무시 무시할 것입니다.
.NET, 재사용 가능한 단일 스레드 DLL 어셈블리, 순수한 계산 논리는 산들 바람입니다.
그만한 가치가 있습니까, 정말 말할 수 없습니다.
많이 리팩토링합니까? 코드에서 “off by one”과 같은 “멍청한 버그”가 많이 보입니까?
당신이 무엇을 하든지, “당신은 단위 테스트를 가지고 있지 않기 때문에 다른 사람들을 비판하는 사람”이되지 마십시오. 테스트가 도움이된다면, 그렇지 않다면 은총 알과 같지 않습니다.