방금 CS에서 학위를 받았으며 현재 Junior .NET Developer (C #, ASP.NET 및 웹 양식)로 일하고 있습니다. 내가 아직 대학에 있었을 때, 단위 테스트의 주제는 다루어졌지만 실제로 그 이점을 보지 못했습니다. 나는 그것이해야 할 일, 즉 코드 블록이 사용하기에 적합한 지 여부를 결정합니다. 그러나, 실제로 단위 테스트를 작성하지 않아도되고, 필요하다고 느끼지도 않았습니다.

이미 언급했듯이 일반적으로 ASP.NET 웹 양식으로 개발하고 있으며 최근에는 단위 테스트를 작성하려고 생각했습니다. 그러나 이것에 대해 몇 가지 질문이 있습니다.

단위 테스트는 종종 "모의 (mocks)"를 작성함으로써 이루어진다는 것을 읽었습니다. 이 개념을 이해하고 있지만 완전히 동적 인 웹 사이트에 대한 모의를 작성하는 방법과 거의 모든 것이 데이터베이스의 데이터에 의존하는 곳을 알 수없는 것 같습니다. 예를 들어 : 나는 ItemDataBound 이벤트 등을 가진 많은 리피터를 사용합니다 (다시 알려지지 않은 데이터에 따라 다름).

질문 1 번 : ASP.NET 웹에 대한 단위 테스트 작성이 자주 수행되는 작업이며, "동적 환경"문제를 어떻게 해결합니까?

제가 개발할 때 많은 시행 착오를 겪습니다. 그것은 내가하고있는 일을 모른다는 것을 의미하지는 않지만 일반적으로 코드를 작성 Ctrl F5하고 어떤 일이 발생했는지 봅니다. 이 접근 방식이 대부분의 경우 작업을 수행하지만 때로는 약간의 경험이 없기 때문에 조금 실마리가 없다는 느낌이 들기도합니다. 나는 때때로 이와 같이 많은 시간을 낭비합니다.

질문 2 번 : 단위 테스트 작성을 시작하라고 조언 하시겠습니까? 나는 그것이 실제 구현에 도움이 될 것이라고 생각하지만 다시 느려질 수 있다고 생각합니다.

내 의견으로는 : 네, 그렇습니다.

1. 변경 사항에 대한 확신을줍니다 (다른 모든 것이 여전히 작동 중임). 이 자신감은 코드를 작성하는 데 필요한 것입니다. 그렇지 않으면 변경하기를 두려워 할 수 있습니다.

2. 그들은 당신의 코드를 더 잘 만듭니다; 가장 간단한 실수는 단위 테스트에서 조기에 발견됩니다. 버그를 조기에 발견하고 수정하는 것은 응용 프로그램이 제작되는 등 나중에 수정하는 것보다 항상 저렴합니다.

3. 코드는 작동 방식 및 사용 방법에 대한 다른 개발자를위한 설명서 역할을합니다.

가장 먼저 겪는 문제는 ASP.NET 자체가 단위 테스트 작성에 도움이되지 않는다는 것입니다. 선택 사항이 있으면 단위 테스트를 염두에두고 작성된 ASP.NET MVC를 사용 하십시오. ASP.NET MVC를 사용할 수없는 경우 ASP.NET에서 MVP 패턴을 사용해야 최소한 논리를 쉽게 테스트 할 수 있습니다.

게다가 단위 테스트 작성에 능숙해야합니다. TDD를 연습하면 코드를 테스트 할 수 있습니다. 즉, 멋지고 깨끗합니다.

연습하고 짝을 지어 줄 것을 권합니다. 읽는 동안:

• 민첩한 소프트웨어 개발, 원칙, 패턴 및 사례 [양장본]
• 헤드 퍼스트 디자인 패턴
• GOF 디자인 패턴 성경
• Roy Osherove의 단위 테스트에 대한 첫 번째 소개
• 단위 테스트 패턴 성경

또는 첫 번째 개요 :

• 고체
• Xunit 테스트 패턴

아니.

단위 테스트의 개념은 단위 테스트가 발명되기 전부터 잘못된 것으로 알려진 전제를 기반으로합니다. 테스트에서 코드가 올바른지 확인할 수 있다는 생각입니다.

모두 통과하는 테스트가 많으면 한 가지만 증명할 수 있습니다. 모두 통과하는 테스트가 많이 있습니다. 테스트중인 테스트가 사양과 일치한다는 것을 증명하지는 않습니다. 테스트를 작성할 때 고려하지 않은 오류가 코드에 없다는 것을 증명하지는 않습니다. (그리고 당신이 테스트하려고 생각한 것은 당신이 집중하고 있던 가능한 문제 였으므로 어쨌든 그것들을 올바르게 얻었을 것입니다!) 그리고 마지막으로, 코드 자체 인 테스트가 버그가 없습니다. (마지막으로 결론을 내리면 거북으로 끝납니다 .)

Djikstra는 개념 휴지통에 1988 년에 돌아 오는 길에 테스트로서의 증명 정확성, 그리고 그가 쓴 것은 오늘 마찬가지로 유효합니다 :

프로그램 테스트가 버그의 존재를 설득력있게 보여줄 수는 있지만, 그 부재를 보여줄 수는 없다고 지적 된 지 20 년이 지났습니다. 이 잘 알려진 발언을 솔직하게 인용 한 후, 소프트웨어 엔지니어는 요크의 연금술사와 마찬가지로 오늘의 순서로 돌아가서 그의 크리 소 코스 믹 정화를 계속 개선 한 테스트 전략을 계속 개선합니다.

단위 테스트의 또 다른 문제점은 코드와 테스트 스위트간에 긴밀한 연결을 생성한다는 것입니다. 코드를 변경하면 일부 테스트가 중단되는 버그가 나타날 것으로 예상됩니다. 그러나 요구 사항 자체가 변경되어 코드를 변경하는 경우 많은 실패한 테스트가 발생하며 각 테스트를 수동으로 진행하여 테스트가 여전히 유효한지 여부를 결정해야합니다. (그리고 기존 테스트하는 것이 또한 비록 적은 일반, 가능 해야 당신이 변경 될 필요가 무엇인가를 변경하는 것을 잊었다 때문에 무효가 아직 전달합니다.)

단위 테스트는 실제로 훌륭한 프로그래머가 아니더라도 작업 코드를보다 쉽게 ​​작성할 수 있도록 개발 된 긴 개발 페이드 중 최신입니다. 그들 중 누구도 약속을 지키지 않았으며,이 약속도 이행하지 못했습니다. 실제로 작업 코드를 작성하는 방법을 아는 바로 가기는 없습니다 .

안정성과 신뢰성이 가장 중요한 경우 자동 테스트가 실제로 유용하다는 일부 보고서가 있습니다. 예를 들어, SQLite 데이터베이스 프로젝트입니다. 그러나 신뢰성 수준을 달성하는 데 필요한 대부분의 프로젝트는 거의 비 경제적입니다. 거의 1200 : 1의 테스트 대 실제 SQLite 코드 비율입니다. 대부분의 프로젝트는 그것을 감당할 수 없으며 어쨌든 필요하지 않습니다.

학교의 작은 코드 조각을 테스트하기위한 주요 방법을 작성하는 것의 이점을 본 적이 있다면 단위 테스트는 동일한 연습의 전문가 / 기업 버전입니다.

또한 코드 작성, 로컬 웹 서버 시작, 문제의 페이지 탐색, 데이터 입력 또는 적절한 테스트 시드에 대한 입력 설정, 양식 제출 및 결과 분석 ...의 작성 및 적중에 대한 오버 헤드를 상상하십시오. nUnit 실행 버튼.

재미있는 이미지도 있습니다 ...

나는이 이미지를 여기에서 발견했다 :
http://www.howtogeek.com/102420/geeks-versus-non-geeks-when-doing-repetitive-tasks-funny-chart/

단위 테스트 에는 요즘 신비한 것이 있습니다. 사람들은이를 100 % 테스트 범위가 성배 인 것처럼, 단위 테스트가 소프트웨어를 개발하는 유일한 방법 인 것처럼 취급합니다.

그들은 요점을 놓치고있다.

단위 테스트 는 답이 아닙니다. 테스트 입니다.

이제이 논의가 나올 때마다 누군가 (종종 나조차도)는 Dijkstra의 말을 인용 할 것이다. Dijkstra는 옳습니다. 테스트는 소프트웨어가 의도 한대로 작동 함을 입증하기에 충분하지 않습니다. 그러나 그것은이다 필요한 : 어떤 수준에서, 할 수 있어야한다 보여 해당 소프트웨어가 사용자가 원하는 일을한다.

많은 사람들이 손으로 테스트합니다. 확고한 TDD 애호가조차 수동 테스트를 수행하지만 때로는 인정하지는 않습니다. 도움이 될 수 없습니다. 회의실에 들어가기 전에 고객 / 보스 / 투자자 등에 게 소프트웨어를 시연하기 전에 직접 작동하여 작동하는지 확인할 수 있습니다. 거기 아무 문제 없습니다, 그냥 모든 것을 수동으로 그것을 통해 실행하지 않고 원활 기대에 사실 그것은 미친 것 - 즉, 그것을 테스트 - 100 % 단위 테스트 범위와 테스트에서 최고의 자신감을 가지고 경우에도 .

그러나 소프트웨어를 구축하는 데 필요한 경우에도 수동 테스트로 는 충분 하지 않습니다 . 왜? 수동 테스트는 지루하고 시간이 많이 걸리며 사람이 수행하기 때문입니다. 그리고 인간은 지루하고 시간이 많이 걸리는 작업을 수행하는 데 악명 높은 것으로 악명 높습니다.

반면에 기계 는 지루하고 시간 소모적 인 작업을 수행하는 데 탁월 합니다. 결국 컴퓨터가 발명되었습니다.

따라서 테스트 는 매우 중요하며 자동화 된 테스트 는 테스트가 일관되게 수행되도록하는 유일한 방법입니다. 그리고 소프트웨어가 개발됨에 따라 테스트하고 다시 테스트하는 것이 중요합니다. 여기에 또 다른 대답은 회귀 테스트 의 중요성을 나타 냅니다. 소프트웨어 시스템의 복잡성으로 인해 시스템의 한 부분이 자주 보이지 않는 변경으로 인해 시스템의 다른 부분에서 의도하지 않은 변경 (예 : 버그)이 발생할 수 있습니다. 테스트를하지 않으면 의도하지 않은 변경 사항을 발견 할 수 없습니다. 테스트에 대한 신뢰할 수있는 데이터를 얻으려면 체계적인 방식으로 테스트를 수행해야합니다. 즉, 일종의 자동 테스트 시스템이 있어야합니다.

이 모든 것이 단위 테스트와 어떤 관련이 있습니까? 글쎄, 단위 테스트는 인간이 아닌 기계에 의해 실행됩니다. 따라서 많은 사람들이 자동화 테스트가 단위 테스트 와 같다는 잘못된 인상을 받고 있습니다. 그러나 이것은 사실이 아닙니다. 단위 테스트는 아주 작은 자동화 된 테스트 일뿐 입니다.

이제 작은 자동화 테스트 의 가치는 무엇 입니까? 장점은있는 소프트웨어 시스템의 구성 요소를 테스트하는 것입니다 분리 가능, 보다 정확한 테스트의 타겟팅 및 디버깅에 보조를 . 그러나 단위 테스트가 본질적으로 고품질 테스트를 의미하는 것은 아닙니다 . 더 세부적인 수준의 소프트웨어를 다루기 때문에 종종 고품질 테스트로 이어집니다. 그러나 컴포지트 부품이 아닌 완전한 시스템의 동작을 완전히 테스트하고 철저히 테스트 할 수 있습니다.

그러나 100 % 단위 테스트 범위에서도 시스템을 철저히 테스트하지 못할 수 있습니다. 개별 구성 요소는 완벽하게 격리되어 작동 할 수 있지만 함께 사용할 경우 여전히 실패합니다. 따라서 단위 테스트는 매우 유용 하지만 소프트웨어가 예상대로 작동하는 데 충분하지 않습니다 . 실제로 많은 개발자가 자동 ​​통합 테스트, 자동 기능 테스트 및 수동 테스트로 단위 테스트를 보완합니다.

단위 테스트에서 가치가 보이지 않는 경우 가장 좋은 시작 방법은 다른 종류의 자동 테스트를 사용하는 것입니다. 웹 환경에서 Selenium 과 같은 브라우저 자동화 테스트 도구 를 사용하면 비교적 적은 투자로 큰 승리를 거둘 수 있습니다. 발가락을 물에 담그면 자동 테스트가 얼마나 유용한 지 더 쉽게 알 수 있습니다. 자동화 된 테스트가 완료되면 단위 테스트는 현재 진행중인 구성 요소에서만 테스트를 대상으로 할 수 있기 때문에 대규모 통합 또는 엔드 투 엔드 테스트보다 더 빠른 처리 시간을 제공하기 때문에 훨씬 더 의미가 있습니다.

TL; DR : 아직 단위 테스트 에 대해 걱정하지 마십시오 . 먼저 소프트웨어 테스트 에 대해 걱정 하십시오.

그것은 달려있다

이것은 소프트웨어 개발과 관련하여 많은 것을 보게 될 해답이지만 단위 테스트의 유용성은 실제로 얼마나 잘 작성되었는지에 달려 있습니다. 회귀 테스트를 위해 응용 프로그램의 기능을 검사하는 공칭 수의 단위 테스트는 매우 유용 할 수 있습니다. 그러나 함수의 반환을 확인하는 수많은 간단한 테스트는 응용 프로그램에 "단위 테스트가 많으므로"보안이 잘못 될 수 있으며 잘못된 보안 감각을 제공 할 수 있습니다.

또한 개발자로서의 시간은 소중하고 단위 테스트 작성에 소요되는 시간은 새로운 기능을 작성하는 데 소요되는 시간이 아닙니다. 다시 말하지만 이것은 단위 테스트를 작성해서는 안된다는 것이 아니라 모든 단일 공용 기능에 단위 테스트가 필요합니까? 나는 대답이 '아니오'라고 제출할 것이다. 사용자 입력 유효성 검사를 수행하는 코드에 단위 테스트가 필요합니까? 응용 프로그램에서 일반적인 실패 지점 일 가능성이 높습니다.

이것은 경험이 시작되는 영역 중 하나입니다. 시간이 지남에 따라 단위 테스트의 이점을 얻을 수있는 응용 프로그램의 일부를 인식 할 수 있지만 그 시점에 도달하기까지는 시간이 걸릴 것입니다.

대학 수업을위한 프로젝트는 직장에서 작성할 비즈니스 응용 프로그램과 크게 다릅니다. 차이점은 수명입니다. 대학 프로젝트는 얼마나 오래 진행됩니까? 대부분의 경우 첫 번째 코드 줄을 작성할 때 시작하고 마크를 받으면 끝납니다. 실제로는 구현 당시에 만 유효합니다. "출시"는 일반적으로 "죽음"과 같습니다.

비즈니스를 위해 수행 된 소프트웨어는 대학 프로젝트의 출시 시점을 능가하며 비즈니스가 필요로하는 한 계속 살아 있습니다. 어느 것이 매우 깁니다 . 돈에 대해 이야기 할 때 아무도 "쿨러하고 깔끔한 코드"를 갖기 위해 깨진 페니를 쓰지 않을 것입니다. 25 년 전에 C로 작성된 소프트웨어가 여전히 작동하고 충분하다면 (비즈니스 소유자의 요구에 의해 이해되는 바와 같이) 소프트웨어를 유지 관리 (새 기능 추가, 기존 기능 변경 소스 코드 변경 )를 수행해야합니다.

우리는 하나의 매우 중요한 점 회귀에 도달했습니다 . 내가 일하는 곳에는 두 개의 앱을 유지하는 두 팀이 있습니다. 하나는 약 5-6 년 전에 코드 테스트 적용 범위가 거의 * 없었으며, 두 번째는 완전한 테스트 스위트 (단위, 통합 및 그 밖의 것)를 갖춘 첫 번째 응용 프로그램의 최신 버전입니다 . 두 팀 모두 전용 수동 (인간) 테스터가 있습니다. 첫 번째 팀에 새롭고 매우 기본적인 기능을 도입하는 데 얼마나 걸립니까? 3-4 주. 이 시간의 절반은 "다른 모든 것이 여전히 작동하는지 확인"입니다. 수동 테스터에게는 바쁜 시간입니다. 전화가 울리고 사람들이 화를 내고 무언가가 다시 부서집니다. 두 번째 팀은 일반적으로 3 일 이내에 이러한 문제를 처리합니다.

단위 테스트로 코드 오류가 발생하기 쉽고 정확하거나 다른 멋진 단어를 만들 수 있다고 말하지는 않습니다. 둘 다 버그를 마술처럼 사라지게하지 않습니다. 그러나 다른 자동화 소프트웨어 테스트 방법과 함께 사용하면 다른 방법보다 훨씬 유지 관리가 쉬운 응용 프로그램을 만들 수 있습니다. 이것은 큰 승리입니다.

마지막으로 Brian의 의견은 모든 문제를 해결한다고 생각합니다.

(...) 그들은 코드가 당신이 디자인 한 일을하고, 내일 코드가 오늘하는 일을 계속한다고 확신합니다.

오늘과 내일 사이에 누군가가 약간만 변경하면 중요한 보고서 생성기 코드가 중단 될 수 있습니다. 테스트는 고객이 자신에게 조금 앞서 기 전에이 사실을 발견 할 확률을 높입니다.

_{* 코드베이스에 점점 더 많은 테스트를 서서히 도입하지만, 우리는 이러한 것들이 일반적으로 어떻게 보이는지 알고 있습니다.}

ASP.NET 웹 양식에 대한 단위 테스트를 작성하는 경우가 종종 있으며, "동적 환경"문제를 어떻게 해결합니까?

자주 수행되지 않습니다. UI 요소로 작업하는 것은 단위 테스트가 좋은 것이 아닙니다. 프로그래밍 방식으로 올바른 것이 화면의 올바른 위치에 있는지 확인하는 좋은 방법이 없기 때문입니다.

단위 테스트 작성을 시작하도록 조언 해 주시겠습니까? 실제 구현에서 도움이 될 수 있다고 생각하지만 다시 느려질 수 있습니다.

해당되는 경우 가능합니다. 특정 사례를 반복 가능한 방식으로 확인하는 데 매우 도움이 될 수 있습니다. 귀찮은 변경에 대한 '마찰'과 더 나은 변경을 할 때 안전 장치 역할을합니다.

한 가지주의 할 점은 일반적으로 속도가 느려진다는 것입니다.

괜찮습니다

약간의 시간을 투자하면 버그를 잡아 내고 버그의 재발을 방지하며 코드가 썩지 않도록 코드의 다른 개선 작업을 수행하는 것이 다소 편해져 향후 시간을 절약 할 수 있습니다.

방금 CS에서 학위를 받았으며 현재 주니어 .NET 개발자 (C # 및 일반적으로 ASP.NET, ASP.NET MVC가 아닌 웹 양식)로 일하고 있습니다. 내가 아직도 대학에 있었을 때, 단위 테스트의 주제는 다루어졌지만 실제로 그 이점을 보지 못했습니다.

크게 프로그래밍하지 않았기 때문입니다.

나는 그것이해야 할 일을 이해합니다-코드 블록인지 여부는 사용하기에 적합합니다.하지만 실제로 단위 테스트를 작성하지 않아도됩니다. (또는> 내가 필요하다고 느낀 적이있다 ..)

단위 테스트를 작성하면 코드가 테스트 가능하고 문서화되고 신뢰할 수있는 지정된 정신 구조를 준수해야합니다. 당신이 주장하는 것 이상입니다.

단위 테스트는 종종 "모의 (mocks)"를 작성함으로써 일어난다는 것을 읽었습니다. 나는이 개념을 이해하지만 완전히 역동적 인 웹 사이트에 대한 모형을 작성하는 방법과 데이터베이스의 데이터에 거의 모든 것이 의존하는 곳을 알 수없는 것 같습니다.

잘 정의되고 하드 코딩 된 데이터로 채워진 모델 클래스를 리턴하는 모의 클래스로 데이터베이스 액세스를 모의하십시오. 또는 , 조명기 데이터로 테스트 데이터베이스를 채우고 거기서부터 작업하십시오.

-단위 테스트 작성을 시작하도록 조언 해 주시겠습니까?

당근 빠따 지. Beck의 "Test Driven Development"를 먼저 읽으십시오 .

실제 구현에서 도움이 될 수 있다고 생각하지만 다시 느려질 수 있습니다.

이제 속도가 느려집니다. 그러나 며칠이 아닌 몇 시간 동안 디버깅해야하는 경우 마음이 바뀔 것입니다.

모든 조언을 부탁드립니다 :)

테스트. 날 믿어. 불행히도 관리 정책이어야하지만 시간을 절약 할 수 있습니다. 테스트는 현재와 미래에 있습니다. 플랫폼을 변경하고 테스트를 실행해도 여전히 작동하는 경우 작업이 예상대로 작동한다는 것을 알고 있습니다.

편집 : 물론 TDD 프로 / 콘 dogpile에 합류하여 질문 # 1을 건너 뛰었습니다.

1-ASP.net 웹 양식에서 단위 테스트 구현

우선, MVC와 함께 갈 수 있다고 생각되면, 기이 한 동굴 곰처럼 싸워야합니다. 프론트 엔드 / UI 개발자 인 .net MVC는 .net의 혐오를 막는 데 도움이 되었기 때문에 지금까지 겪었던 모든 Java 웹 솔루션을 혐오하는 데 더 집중할 수 있습니다. 웹 폼은 서버와 클라이언트 측 사이의 경계를 실제로 흐리게하기 때문에 단위 테스트는 문제가됩니다. 단위 테스트를 시도 할 때마다 데이터 조작에 중점을두고 웹폼이 사용자 입력의 정규화를 처리한다고 가정합니다.

2-단위 테스트가 먼저 가치가 있는지 여부 :

좋아, 완전 공개 :

• 나는 대부분 스스로를 가르칩니다. 공식적인 교육은 하나의 JavaScript, PHP 및 C # 클래스와 OOP 원칙에 대한 개인적인 연구 및 디자인 패턴과 같은 자료를 읽습니다.

하나,

• 나는 주로 클라이언트 측 웹을 위해 글을 쓰고 실제 프로그래밍 부분은 동적 타이핑, 일급 함수 및 객체 변경과 관련하여 가장 빠르고 느슨한 언어 중 하나입니다.

즉, 동일한 컴파일러 또는 가상 머신을 작성하지 않습니다. 나는 4-20 개의 3 가지 언어에 대한 다양한 해석을 썼다. 오늘날보다 훨씬 더 다양합니다. 그리고 아니요, 일회용 앱을 위해 JQuery를 연결하는 어린이는 아닙니다. UI 요소가 복잡하여 상당히 정교한 것을 만들고 유지 관리하는 데 도움이됩니다.

그렇습니다. 여기서 약간의 조정이 가능하고 디자인 기술이 완전하지 않거나 1-2 품질 개발 문제로 평범한 개발자를 대량으로 던질 경우 대규모 실패를 일으킬 수있는 기회가 많이 있습니다.

TDD가 무엇을해야하는지에 대한 나의 이해는 테스트가 디자인을보다 신중하게 고려하고 요구 사항에 계속 집중하도록하는 것입니다. 충분히 공평하지만 여기서 문제는 인터페이스 디자인, 미묘하지만 근본적으로 다른 무언가로 인터페이스 테스트를 위해 디자인하는 것입니다. 나에게 차이점은 엄마가 의미를 짐작할 필요가없는 선명한 그림을 그린으로 가득 채울 정도로 빨리 녹색으로 채워 넣을 수 있기 때문에 테이블에 크레용을 때리고 "완료!" " 우선 순위를 프로세스와 디자인보다 결과로 전환함으로써 기본적으로 가비지 코드의 지속적인 구현을 권장합니다. 이는 일반적으로 문제의 근본 원인입니다.

물론 "실제 시점이 아님"이지만 종종 단위 테스트의 부수적 인 이점이있어 회귀 오류를 감지하는 데 도움이됩니다. TDD 옹호자들은 이것이 실제로 목표인지 또는 단지 멋진 부작용 인 IMO인지에 대해 약간 불안해하는 경향이 있습니다. 코드, 특히 JavaScript와 같은보다 동적 인 언어에서 긴 종속 체인에서 가능한 모든 시나리오를 예측할 수 있다고 가정하는 것은 어리석은 일입니다.

JS에는 자동 테스트를위한 장소가 있지만 다른 코드와 접촉하는 코드의 모든 단일 '단위'에 단위 테스트를 첨부하는 것보다 시간을 훨씬 더 잘 활용할 수 있습니다. 작업을 복제하거나 의도 된 사용법이 의미 상 모호한 가비지 객체. DRY 원칙을 따릅니다. 재사용의 가치가 명백해지면 (분 전이 아님) 재사용 / 휴대 성을 위해 추상화합니다. 당신은 스틱 원칙보다 더 많은 당근을 따르는 일관된 프로세스와 방법을 확립합니다 (즉, 물건을 잘못 사용하고 싶어하는 올바른 방법을 사용하는 것은 너무 쉽습니다). 그리고 foo와 bar의 모든 것을 사랑하기 위해 코드 재사용의 수단으로 대규모 계단식 상속 체계 반 패턴에 빠지지 마십시오.

위의 모든 내용이 제 코드에서 진단하기 어려운 버그를 심각하게 줄이는 데 도움이되었으며 브라우저 세트를 가진 개발자로 등장한 사람에게 " "지정되지 않은 파일의이 가상 줄 번호에 'Object'유형의 객체에 문제가 있습니다." (gee, 고마워 IE6) TDD는 내 업무 라인에서 이러한 것들을 장려하지 않을 것입니다. 포인트 A와 B 사이에있는 것이 작동하는 한 실제로 중요하지 않은 프로세스에 비해 100 % 결과로 초점을 이동합니다. 처음에는 많은 혼란을 겪지 않으면 서 물건을 읽을 수 있고 휴대 가능하며 쉽게 수정할 수 있도록하는 데 시간이 낭비됩니다.

아니면 어쩌면 나는 내가 뿌리를두고있는 패러다임에 대해서만 지나치게 절제하고 있지만, 내 의견으로는, 처음부터 올바르게하는 것은 당신이나 다른 사람들이 팀이 잘못했습니다. 그리고 단순히 구현하는 것보다 디자인을 고려하도록 강요해서는 안됩니다. 디자인은 모든 프로그래머의 제단이어야합니다. 그리고 옳은 일을하도록 강요하거나 당신에게서 자신을 보호하는 것은 뱀 기름 한 병, IMO를 위해 예약 된 것과 같은 의심으로보아야합니다. 현대 IT의 스네이크 오일 및 일반 개발은 아직 모르는 경우 액체 톤으로 판매됩니다.

내 경험상, 단위 테스트는 테스트 를 시작하고 테스트 중심 개발 과 함께있을 때 실제로 매우 유용합니다 . 이유는 다음과 같습니다.

• 단위 테스트를 수행하면 코드를 작성하기 전에 원하는 내용과이를 확인하는 방법을 생각해야합니다 . TDD 시나리오에서는 먼저 테스트를 작성합니다. 따라서 작성하려는 코드가 무엇을해야하는지, 코드를 작성하여 "녹색"으로하는 "적색"테스트를 작성하기 위해 코드가 성공적으로 수행되었는지 확인하는 방법을 알아야합니다. 넘기다. 대부분의 경우이 테스트를 통과하기 위해 작성하려고하는 알고리즘에 대해 조금 더 생각하게되는데, 이는 논리 오류와 "코너 사례"를 줄이므로 항상 좋습니다. 테스트를 작성하는 동안 "어떻게 실패 할 수 있는가 "와 " 여기서 테스트 하지 않은 것은 무엇입니까"라는 생각 이 들며 이는 더욱 강력한 알고리즘으로 이어집니다.

• 단위 테스트는 작성하려는 코드가 어떻게 소비 될지에 대해 생각하게합니다 . TDD를 배우기 전에 여러 가지 방법으로 종속성을 기대하는 코드를 작성한 다음 완전히 다른 방식으로 작동하는 동료가 작성한 종속성을 부여 받았습니다. 이것은 여전히 ​​TDD를 사용하여 가능하지만 작성중인 단위 테스트는 작성중인 오브젝트의 사용법 예입니다. 해당 오브젝트의 사용 예입니다. 그런 다음 소비하기 쉬운 방식으로 객체를 작성하고 필요한 경우 적응할 수 있습니다 (사전 정의 된 인터페이스에 프로그래밍하는 것이 TDD가 필요없는이 문제에 대한 전체적인 솔루션 임).

• 단위 테스트를 통해 "테스트하여 코딩"할 수 있습니다 . ReSharper와 같은 리팩토링 도구를 사용하면 가장 친한 친구가 될 수 있습니다. 테스트에서 사용법을 정의 할 때이를 사용하여 새로운 기능의 골격을 정의 할 수 있습니다.

  예를 들어, MyClass라는 새 객체를 만들어야한다고 가정 해보십시오. 먼저 MyClass 인스턴스를 작성하십시오. "하지만 MyClass는 존재하지 않습니다!"라고 ReSharper가 불평합니다. Alt + Enter를 누르면 "만들기"라고 말합니다. 그리고 당신은 클래스 정의를 가지고 있습니다. 테스트 코드의 다음 줄에서는 MyMethod 메서드를 호출합니다. "하지만 존재하지 않습니다!"라고 ReSharper는 말합니다. "만들면"다른 Alt + Enter를 사용하여 반복합니다. 몇 번의 키 누름으로 새 코드의 "골격"을 정의했습니다. 사용법을 계속 구체화하면 IDE는 무언가가 맞지 않을 때 알려줍니다. 일반적으로 솔루션은 IDE 또는 IDE에 연결된 도구가이를 수정하는 방법을 알기에 충분히 간단합니다.

  더 극단적 인 예는 "Triple-A"모델을 따릅니다. "배열, 행위, 주장". 모든 것을 설정하고 테스트중인 실제 로직을 수행 한 다음 로직이 올바른지 확인하십시오. 이런 식으로 코딩하면 솔루션을 테스트에 코딩하는 것이 매우 자연 스럽습니다. 그런 다음 몇 번의 키 누름으로 해당 로직을 추출하여 프로덕션 코드에서 사용할 수있는 위치에 놓고 로직의 새로운 위치를 가리키는 테스트를 약간 변경하십시오. 이 방법을 사용하면 테스트하는 장치에 여전히 액세스 할 수 있어야하므로 재사용하기 쉬운 모듈 식 코드로 코드를 설계해야합니다.

• 단위 테스트는 생각할 수있는 수동 테스트보다 훨씬 빠르게 진행됩니다. 더 큰 프로젝트의 경우 매우 신속하게 충족되는 지점이 있는데, 여기서 수동 테스트에 소요되는 시간을 줄임으로써 단위 테스트의 오버 헤드가 자동으로 지불되기 시작합니다. 방금 작성한 코드를 항상 실행해야합니다. 일반적으로 대규모 프로그램을 시작하고 UI를 탐색하여 동작을 변경 한 상황을 설정 한 다음 UI를 통해 또는 생성 된 데이터 형식으로 결과를 다시 확인하여 수동으로 수행했습니다. 코드가 TDD 된 경우 단위 테스트 만 실행하면됩니다. 좋은 단위 테스트를 작성하는 경우 후자 옵션이 이전보다 몇 배 빠릅니다.

• 단위 테스트는 회귀를 잡습니다 . 다시, 내가 들어가는 TDD를 배우고 코드 조각을 외과 적으로 변경했다고 생각하고 변경 사항이보고 된 상황에서 잘못된 동작을 수정했는지 (또는 새로운 원하는 동작을 생성했는지) 확인했습니다. 변경 사항이 동일한 코드 블록을 재사용하는 완전히 다른 모듈에서 다른 코너 케이스를 위반 한 것을 발견하기 위해 릴리스를 위해 체크인했습니다. TDDed 프로젝트에서 변경하려는 변경 사항을 확인하고 변경 한 다음 전체 제품군을 실행하는 테스트를 작성하고 코드의 다른 모든 용도가 TDD로 변경되어 변경 사항이 발생한 경우 해당 테스트를 수행 할 수 있습니다. 다른 것들은 실패 할 것이고, 나는 조사 할 수 있습니다.

  개발자가 잠재적 인 변경으로 인해 영향을받을 수있는 모든 코드 줄을 수동으로 찾아 테스트해야한다면 변경의 영향을 판단하는 비용으로 인해 변경이 불가능 해지기 때문에 아무것도 할 수 없었습니다. 최소한 여러 곳에서 사용될 수있는 물건을 절대로 만지지 않기 때문에 SOLID가 아니므로 쉽게 유지 관리 할 수있는 것은 없습니다. 대신 SRP 및 아마도 OCP를 위반하고 코드베이스를 패치 워크 퀼트로 천천히 돌리는이 경우를 위해 매우 유사하지만 통합 된 마이너 변경 솔루션을 롤백합니다.

• 단위는 일반적으로 유리한 방식으로 모양 아키텍처를 테스트 합니다. 단위 테스트는 다른 로직과는 별도로 수행되는 테스트입니다. 코드를 테스트 단위 수 있도록하기 위해, 다음, 당신은 같은 방식으로 코드를 작성해야합니다 당신이 할 수있는그것을 분리하십시오. 느슨한 결합 및 의존성 주입과 같은 우수한 설계 결정은 TDD 프로세스에서 자연스럽게 흔들립니다. 테스트에서 "부작용"을 생성하지 않고 테스트중인 상황에 대한 입력을 생성하거나 출력을 처리하는 "모의"또는 "스텁"을 주입 할 수 있도록 종속성을 주입해야합니다. TDD의 "먼저 사용"사고 방식은 일반적으로 느슨한 결합의 본질 인 "인터페이스 코딩"으로 이어집니다. 이러한 우수한 설계 원칙을 통해 대량의 코드베이스를 변경하지 않고도 전체 클래스를 교체하는 등 생산을 변경할 수 있습니다.

• 단위 테스트 는 코드 작동을 증명 하는 대신 코드가 작동 함을 보여줍니다 . 언뜻보기에 당신은 단점을 생각할 수 있습니다. 반드시 증명이 데모보다 낫습니까? 이론은 훌륭합니다. 계산 및 알고리즘 이론은 우리 작업의 기초입니다. 그러나 알고리즘 의 정확성에 대한 수학적 증거 는 구현 의 정확성에 대한 증거 가 아닙니다 . 수학적 증거는 알고리즘을 고수하는 코드 가 정확 해야한다는 것을 보여줍니다 . 단위 테스트는 실제로 작성된 코드는 당신이 그것을 할 것이라고 생각했던 않으며, 증거 따라서는 것을 보여주고 있다 올바른. 이것은 일반적으로 이론적 증거보다 훨씬 더 가치가 있습니다.

이제 말했듯이 단위 테스트에는 단점이 있습니다.

• 모든 것을 단위 테스트 할 수는 없습니다. 단위 테스트에서 다루지 않는 LOC 수를 최소화하도록 시스템을 설계 할 수 있지만 단위 테스트 할 수없는 시스템의 특정 영역이있을 것입니다. 다른 코드에서 사용하는 경우 데이터 액세스 계층을 조롱 할 수 있지만 데이터 액세스 계층 자체에는 많은 부작용이 포함되며 일반적으로 리포지토리 또는 DAO의 단위 테스트를 수행하는 것은 불가능합니다. 마찬가지로 파일을 사용하거나 네트워크 연결을 설정하는 코드 등에는 부작용이 내장되어 있으므로 해당 코드를 단위 테스트 할 수 없습니다. UI 요소는 종종 단위 테스트를 할 수 없습니다. 이벤트 핸들러와 같은 코드 숨김 메소드를 테스트하고 생성자를 단위 테스트하고 핸들러가 연결되어 있는지 확인할 수 있습니다. 그러나 사용자가 특정 그래픽 요소에서 마우스를 클릭하고 핸들러가 호출되는 것을 대체하는 코드 내 대체는 없습니다. 적절하게 단위 테스트 할 수있는 것과 불가능한 것 사이에서 이러한 경계에 도달하는 것을 "샌드 박스 가장자리 긁기"라고합니다. 이 시점을 넘어 서면 통합 테스트, 자동 수락 테스트 및 수동 테스트를 사용하여 동작을 확인하는 것으로 제한됩니다.

• 단위 테스트의 많은 장점은 TDD없이 적용되지 않습니다. 코드를 작성하고 코드를 실행하는 테스트를 작성하는 것이 완벽하게 가능합니다. 그것들은 여전히 ​​"단위 테스트"이지만, 코드를 먼저 작성함으로써 "테스트 우선"개발에 내재 된 많은 장점을 잃게됩니다. 코드는 반드시 쉽게 테스트하거나 생산에 사용될 수있는 방식으로 설계되지는 않습니다 ; 테스트를 작성하고 생각하지 않은 것에 대해 생각할 때 내재 된 "이중 점검"사고 프로세스를 얻지 못합니다. 테스트를 통해 코딩하지 않습니다. 코드를 작성하고 수동으로 테스트하여 작동하는지 확인한 경우 실패한 단위 테스트를 코드 또는 테스트로 코딩하십시오. 주요 장점은 회귀 방지 (이전에 테스트를 통과 한 코드가 실패하면 경고)와 고속 검증 및 수동 테스트입니다. TDD의 상실

• 단위 테스트로 인해 오버 헤드가 발생 합니다. 간단히 말해서, 작성중인 코드를 테스트하기위한 코드를 작성하는 것입니다. 이것은 반드시 개발 프로젝트의 총 LOC를 증가 시키며, 예를 들어 테스트 용 LOC는 실제 프로젝트의 LOC를 초과 할 수 있습니다. 순진한 개발자와 비 개발자는이 상태를보고 테스트가 시간 낭비라고 말합니다.

• 단위 테스트에는 훈련이 필요합니다. 코드베이스 (적절한 코드 적용 범위)를 적절하게 실행하는 테스트를 작성하고 정기적으로 실행해야합니다 (변경 사항을 적용 할 때마다 전체 제품군을 실행해야 함). 모든 것을 "녹색"으로 유지해야합니다 ( 모든 테스트 통과). 문제가 발생하면 기대에 맞지 않는 코드를 수정하거나 테스트의 기대치를 업데이트하여 문제를 해결해야합니다. 테스트를 변경하면 "이유"를 묻고 자신을주의 깊게 관찰해야합니다. 현재 동작에 맞게 실패한 어설 션을 단순히 변경하거나 실패한 테스트를 제거하는 것은 매우 유혹적입니다. 그러나 이러한 테스트는 요구 사항을 기반으로해야하며 두 가지가 일치하지 않으면 문제가있는 것입니다. 이 작업을 수행하지 않으면

• 단위 테스트에는 더 많은 장비가 필요합니다. 위의 훈련에 대한 일반적인 해결책과 인간이 게으르고 유쾌한 경향이있는 전형적인 해결책은 TeamCity, CruiseControl 등과 같은 "Continuous Integration"소프트웨어 패키지를 실행하는 "빌드 봇"입니다. 코드 적용 범위 메트릭스 및 "트리플 -C"(코딩 규칙 준수, la FxCop)와 같은 다른 컨트롤이 있습니다. 빌드 봇의 하드웨어는 합리적으로 성능이 우수해야하며 (그렇지 않으면 평균 팀이 수행 할 코드 체크인 속도를 유지하지 못함) 봇의 체크인 절차는 최신 상태로 유지되어야합니다 ( 새로운 단위 테스트 라이브러리가 작성되면, 단위 테스트를 실행하는 빌드 스크립트는 해당 라이브러리에서 보이도록 변경되어야합니다. 이것은 소리보다 일이 적습니다. 그러나 일반적으로 다양한 빌드 프로세스의 핵심 요소가 어떻게 작동하는지 알고 있으며 (스크립트에서 자동화하고 해당 스크립트를 유지 관리 할 수있는) 팀 구성원 중 최소한 몇 명이 기술 지식을 필요로합니다. 또한 빌드가 "깨질 때"주의를 기울이고 새로운 것을 체크인하기 전에 빌드가 깨지는 원인을 수정하십시오.

• 단위 테스트를 통해 코드를 비 이상적인 방식으로 설계 할 수 있습니다 . TDD는 일반적으로 코드의 모듈 성과 재사용성에 좋지만, 코드의 적절한 접근성에 해로울 수 있습니다. 프로덕션 라이브러리에 배치 된 객체 및 멤버는 단위 테스트에서 직접 사용하는 경우 개인용 또는 내부 용이 될 수 없습니다. 이로 인해 다른 코더, 이제 객체를보고 라이브러리에있는 다른 것을 사용해야 할 때 사용하려고 할 때 문제가 발생할 수 있습니다. 코드 검토가 도움이 될 수 있지만 문제가 될 수 있습니다.

• 단위 테스트는 일반적으로 "빠른 응용 프로그램 개발"코딩 스타일을 금지합니다.. 단위 테스트를 작성하는 경우 "빠르고 느슨하게"코딩하지 않습니다. 그것은 일반적으로 좋은 일이지만, 통제 범위 밖에서 마감 기한이 지났거나 매우 작은 범위의 변화를 구현할 때 이해 관계자 (또는 상사)가 왜이 모든 일이 왜 일어나야하는지 궁금해하고 있습니다. 한 줄의 코드를 변경하면 적절한 단위 테스트 스위트를 작성하고 유지 관리하는 것이 불가능할 수 있습니다. 애자일 프로세스는 일반적으로 개발자에게 시간 요구 사항에 대한 언급을 허용함으로써이를 지원합니다. 판매원이해야 할 일은 "우리는 할 수있다"라고 말하고 프로세스는 "우리는 할 수 없다"고 실제로주의를 기울여야하는 작업을 수행해야하는 사람들과 관련이없는 한 수수료 검사를받습니다. 그러나 모든 사람이 민첩한 것은 아니며 민첩성에는 자체 한계가 있습니다.

단위 테스트는 올바르게 사용될 때 유용합니다. 논리에 여러 가지 문제가 있습니다.

케빈은“개발 중일 때 많은 시행 착오를 겪고있다.

우연의 일치 프로그래밍을보십시오. 코드가 어떻게해야하는지 이해 한 다음 단위 테스트를 통해 코드를 수행한다는 것을 증명하는 것이 좋습니다. 프로그램을 실행할 때 UI가 중단되지 않았기 때문에 코드가 단순히 작동한다고 가정하지 마십시오!

s writing unit tests for ASP.NET web forms something that is done often

사람들이 웹 양식을 얼마나 자주 테스트하는지 통계 데이터에 대한 지식이 없습니다. 그것은 중요하지 않습니다. UI는 테스트하기 어렵고 단위 테스트도 UI에 연결해서는 안됩니다. 로직을 테스트 할 수있는 클래스 라이브러리 인 계층으로 분리하십시오. 백엔드 로직과 별도로 UI를 테스트하십시오.

So, question number 2: Would you guys advise me to start writing unit tests?

예. 일단 익숙해지면 속도가 빨라집니다. 초기 개발 단계보다 유지 관리에 훨씬 많은 시간과 비용이 소요됩니다. 초기 테스트 및 버그 복구에서도 단위 테스트를 통해 유지 관리가 크게 지원됩니다.

실용적인 수준에서 단위 테스트는 한 가지 중요한 이유로 매우 유용 할 수 있습니다. 한 번에 1 비트의 코드를 테스트 할 수 있습니다.

복잡한 단계의 전체 시퀀스를 작성하고 끝에 디버깅 할 때 많은 버그를 발견하는 경향이 있으며 프로세스를 계속 진행하기 때문에 프로세스가 일반적으로 더 어렵습니다. Visual Studio에서는 빠른 테스트를 생성하고 약간 변경 한 다음 해당 테스트 만 실행할 수 있습니다. 그런 다음 해당 메서드를 호출하는 메서드가이를 사용할 수 있다는 것을 알고 있습니다. 따라서 자신감이 높아집니다.

단위 테스트는 프로그램이 올바른지 증명하지 않습니다! : 단위 테스트는 민감한 코드에서 회귀를 확인하고 작성한 새로운 방법을 테스트 할 수 있습니다.

단위 테스트는 프런트 엔드를 테스트하기위한 것이 아닙니다. 단위 테스트는 작성중인 새로운 방법이나 무언가를 테스트하기 위해 생성하는 작은 프로젝트 또는 코드가 충족해야하는 조건이 아니라 작은 프로젝트로 생각하십시오.

단위 테스트는 공동 작업 환경에서 효과적 입니다. 예를 들어 iOS에서 완전히 호출하는 것과 같이 완전히 다른 기술을 사용하는 동료에게 메소드를 제공 해야하는 경우 단위 테스트를 신속하게 작성하여 그가 원하는 방법 a) 정확한 데이터를 재구성합니다. b) 사양에 따라 수행합니다. c) 거친 병목 현상이 없습니다.

다루지 않은 것 중 하나는 다른 유형의 코드를 테스트하는 것이 복잡하다는 것입니다.

간단한 입력 및 출력으로 처리 할 때는 일반적으로 단위 테스트가 쉽고 테스트 할 코드의 가장 중요한 경우를 염두에두고 테스트를 선택하면 올바른 결과를 얻을 수 있습니다. 그러한 코드에 대한 테스트를 작성하지 않으면 미친 것입니다. 라이브러리에 들어가는 대부분의 코드는이 기준을 충족합니다.

그러나 다른 경우에는 코드가 복잡한 기본 데이터 (일반적으로 데이터베이스이지만 반드시 그럴 필요는 없음)와 함께 재생되거나 매우 복잡한 출력 데이터를 생성하기 때문에 테스트를 위해 거대한 모형을 구성해야합니다. 아주 극단적 인 예를 들어 게임 레벨에 시드 값을 제공하고 단위 테스트는 그다지 유용하지 않습니다. 테스트 케이스의 모든 것을 다루는 것은 일반적으로 파이프의 꿈이며 버그를 발견하면 거의 항상 생각해 본 적이 없으므로 어쨌든 테스트를 구성 할 수 없었습니다.

은 총알이 없으며,은 총알로 묘사 된 것은 지지자가 주장하는 것만 큼 좋지는 않지만 쓸모 없다는 의미는 아닙니다.

ASP.NET 웹 양식 응용 프로그램에 대한 단위 테스트 작성은 일반적이지 않으며 달성하기가 매우 어렵습니다. 그러나 프로젝트가 프로젝트를 건너 뛰어야한다는 의미는 아닙니다.

단위 테스트는 corner stones미션 크리티컬 애플리케이션이며 핵심 기능이 예상대로 수행된다는 안정성과 안정성을 제공합니다.

실제로 웹 양식 개발에 사용될 수 있는 ASP.NET MVP 패턴 을 사용 하면 단위 테스트를 훨씬 쉽게 수행 할 수 있습니다. 그리고 우려의 분리를 소개 할 것이다 ability to write essential unit tests.

보기에 도움이 될만한 참고 자료는 다음과 같습니다.

• ASP.NET Webforms 응용 프로그램 테스트 시작 (MVP 패턴)
• ASP.NET Web Forms MVP를 사용하여 리디렉션 수행 및 테스트
• ASP.NET을 사용한 Model View Presenter-CodeProject

단위 테스트의 목적은 시스템 내부에서 무언가를 깰 수 있다는 두려움없이 코드를 안전하게 변경 (리팩토링, 개선 등) 할 수 있도록하는 것입니다. 이는 코드 변경의 영향을 모두 알지 못하는 경우 (느슨한 커플 링에도 불구하고) 대규모 응용 프로그램에 매우 유용합니다.

예 , 단위 테스트가 유용 하다는 것은 내 경험입니다 .

단위 테스팅은 작성한 코드의 일부를 분리하여 격리 된 상태로 작동하는지 확인하는 것입니다. 이 격리에는 실제로 테스트중인 개체와 통신하기 위해 가짜 또는 모의 개체를 만드는 것이 포함되거나 그렇지 않을 수 있습니다. 객체의 아키텍처에 크게 의존합니다.

단위 테스트는 다음과 같은 다양한 이점을 제공합니다.

기본적으로 이것은 테스트하는 유닛이 개발자가 생각하는 방식대로 작동하도록합니다. 이것은 소리보다 작지만 반드시 개체가 올바르게 작동한다고 말하는 것은 아닙니다. 그것이 작동해야한다고 생각하는 방식으로 작동한다는 것만으로는 단위 테스트없이 필요한 시행 착오 방법보다 훨씬 강력합니다.

또한 개발자가 생각한 방식대로 장치가 계속 작동하도록합니다. 소프트웨어가 변경되어 예기치 않은 방식으로 장치에 영향을 줄 수 있습니다.

또 다른 부작용은 테스트 단위는 것을 의미있다 할 고립되어 일을. 이것은 일반적으로 구체적인 클래스가 아닌 인터페이스에 대한 프로그래밍을 시작하여 결합을 줄이고 응집력을 높이는 것을 의미합니다. 예 : 단순히 코드의 당신의 단위를 가능 이 자연스럽게 코드의 디자인을 향상시킬 단위 테스트를.

하나...

단위 테스트는 테스트의 끝이 아닙니다. 다른 유형의 테스트가 여전히 필요합니다. 예를 들어, 장치가 예상대로 작동한다는 것을 보여 주었더라도 각 장치가 작동하는 장치가 작동하는 방식으로 작동한다는 것을 보여 주어야합니다. 즉, 구성 요소가 서로 올바르게 통합됩니까?

테스트 할 레이어 수가 적은 간단한 앱 (메인 창-> 하위 메뉴)의 경우 변경 사항을 확인하기 위해 실행하도록 컴파일해도됩니다.

테스트중인 페이지를 30 초 동안 탐색해야하는 더 큰 앱의 경우 비용 이 매우 많이 듭니다.

나는 이것에 새로운 측면 (실제로는 오래된 것)을 추가하고 싶다 : 코드가 잘 설계되어 있다면 단위 테스트는 그렇게 유용하지 않다 .

나는 대부분의 프로그래머들이 더 이상 프로그램 설계를하지 않는다는 것을 알고있다. 나는 아직도 그렇다. 그러나 단위 테스트는 TDD 문화에 적응하는 데 다소 시간이 걸리는 필요성이라는 것을 알았다. 내가 작성한 코드뿐만 아니라 공식 테스터도 작성한 코드의 수천 줄의 테스트 당 버그.

더 이상 프로그램 설계를하지 않을 것 같습니다. 현재 사람들은 금형에 압력을 가하지 않을 것입니다. 그러나 단위 테스트는 설계에 비해 매우 낮은 효율의 방법이라는 것을 기억해야합니다.

이것은 dijsktraian 인수입니다. 단위 테스트는 실행하기에 충분히 상세한 프로그램에 대해서만 실행할 수 있습니다.

실제로 코드를 작성하기 전에 코드에 대한 플로우 차트 / 상태 / 액션 다이어그램, 시퀀스 다이어그램, 객체 인벤토리 (및 마지막 AND 최소 클래스 클래스)를 그리면 추적하여 잠재적으로 위협이되는 대부분의 버그를 제거 할 수 있습니다. 당신의 라인과 이름을 확인합니다.

오늘날 클래스 다이어그램은 수백 개의 클래스, 때로는 수천 개의 클래스를 포함하는 코드에서 생성되며 완전히 사용할 수 없습니다. 15 개 이상의 요소를 포함하는 것은 인간의 인식을 넘어서는 것입니다.

10 + -5 개의 클래스가 중요하거나 지금해야 할 일을 알아야하며, 여러 관점에서 코드를 확인할 수 있어야합니다. 각 다이어그램은 현재보고있는 관점을 정확하게 나타내며 수천 개의 버그를 제거합니다. 종이에.

• 유형이 충족되면 동적 코드 체크인 (순서도에 입력 / 출력 유형을 표시하고 연필 또는 다른 색상으로 연결)
• 모든 상태가 처리되는지 확인 (조건의 전체 성을 확인)
• 모든 것을 끝내기 위해 선 추적하기
• 특정 구성 요소가 모든 종속성을 추출하여 서로 관련이 없는지 확인 (보안에 적합)
• 종속성을 연관으로 변환하여 코드 단순화 (종속성은 멤버 메소드가 사용하는 클래스에서 비롯됨)
• 이름 확인, 공통 접두사 찾기, 동의어 지우기 등 ...

훨씬 쉬워요 ...

또한 사용 사례에서 직접 온 경우 내 응용 프로그램이 더 유용하다는 것을 알았습니다. 사용 사례가 잘 작성된 경우 (ACTOR 동사 주제, 관리자가 현금 기계를 열도록 요청합니다) ...

코드 범위의 95 + % 이상으로 코드를 작성했습니다. 물론 단위 테스트를하는 경우도 있습니다. 계산에서 경계 검사를 수행하지만 리팩토링에도 단위 테스트를 사용하지 않아 심각한 회귀 (심각한 : 24 시간 안에 지워지지 않음)를 충족시키지 못했습니다.

때로는 3-4 일 동안 한 줄의 코드를 똑바로하지 않고 그리기 만합니다. 그런 다음 하루에 1500-2000 줄을 입력합니다. 다음 날까지, 그들은 대부분 생산 준비가되었습니다. 때로는 단위 테스트가 작성되고 (범위의 80 % 이상), 때로는 테스터들에게 테스트를 중단하도록 요청하고, 매번, 일부 사람들은이를 검토하여 검토하도록 요청합니다.

아직 단위 테스트에서 아무것도 발견하지 못했습니다.

디자인 사고가 TDD 대신 이루어질 수 있기를 바랍니다 ...하지만 TDD는 훨씬 쉬워요. 마치 망치를 사용하는 것과 같습니다.