이를 수행하지 않는 회사에서 단위 테스트 구현

우리 회사의 소프트웨어 개발 책임자는 "사임"(즉, 해고)되었으며 이제 회사의 개발 방식을 개선하기 위해 노력하고 있습니다. 여기서 만든 모든 소프트웨어에서 단위 테스트를 구현하려고합니다.

개발자의 의견은 다음과 같습니다.

• 우리는 테스트가 중요하다는 것을 알고 있습니다
• 그러나 항상 사양을 변경하므로 시간 낭비가됩니다.
• 그리고 마감 시간이 너무 빡빡해서 어쨌든 테스트 할 시간이 충분하지 않습니다.

CEO의 의견은 다음과 같습니다.

• 회사에서 자동화 된 테스트를 수행하고 싶지만 테스트 방법을 모르겠습니다.
• 큰 사양 문서를 작성할 시간이 없습니다

개발자는 지금 사양을 어떻게 얻습니까? 입소문 또는 PowerPoint 슬라이드. 분명히 큰 문제입니다. 내 제안은 이것입니다 :

• 개발자에게 테스트 데이터 및 단위 테스트 세트를 제공합시다
• 그것이 사양입니다. 원하는 것에 대해 명확하고 정량적으로 관리하는 것은 경영진의 책임입니다.
• 개발자는 필요하다고 느끼는 다른 기능을 테스트에 포함시킬 수 있습니다.

이 상황에 처한 회사에 가본 적이 있다면 어떻게 문제를 해결 했습니까? 이 접근법은 합리적으로 보입니까?

단위 테스트와 시스템 / 수락 테스트라는 두 가지 종류의 테스트를 혼합 한 것 같습니다 . 전자는 하위 레벨에서 작동하며 일반적으로 사용자가 직접 볼 수없는 프로그램 내부에있는 작은 코드 조각 (일반적으로 개별 방법)을 테스트합니다. 후자는 사용자가 보는 것처럼 전체 프로그램을 훨씬 더 세밀하게 테스트합니다. 따라서, 후자 만이 모든 형태의 시스템 사양에 기초 할 수있다.

두 가지 문제를 분리하면 개선 된 개발 프로세스 로 쉽게 넘어갈 수 있습니다. 소프트웨어가 높은 수준으로 지정되지 않은 방식에 관계없이 가능한 빨리 단위 테스트 작성을 시작하십시오 . 개발자가 메소드를 작성하거나 변경할 때마다 구체적인 테스트를 수행하여 단위 테스트가 가능해야합니다. 필자의 경험에 따르면 높은 수준의 요구 사항을 변경하더라도 이러한 낮은 수준의 코드 블록에는 큰 영향을 미치지 않습니다. 코드는 대부분 완전히 다시 작성하거나 다시 작성하지 않고 재배치해야합니다. 따라서 대부분의 기존 단위 테스트는 계속 정상적으로 실행됩니다.

단위 테스트를 가능하게하는 한 가지 중요한 조건은 마감 시한을 경영진이 먼저 결정하지 말고 개발자의 작업 견적을 기반으로해야한다는 것입니다 (개발자는 적절한 단위 테스트를 작성하는 데 필요한 시간을 추정에 포함시켜야 함). 또는 마감 기한이 정해지면 배달 범위를 협상 할 수 있어야합니다. 주어진 많은 수의 개발자가 주어진 시간 내에 일정량의 양질의 작업 만 제공 할 수 있다는 근본적인 진실을 바꿀 수는 없습니다.

이와 병행하여 요구 사항을 명확히하고 문서화하고이를 높은 수준의 승인 테스트로 전환하는 가장 좋은 방법에 대해 논의하십시오. 이 과정은 더 긴 연속적인 개선 과정으로, 전체 조직에서 더 좋고 안정적인 상태에 도달하는 데 몇 년이 걸릴 수 있습니다. 한 가지 설명은 분명히 알 수 있습니다. 큰 사양 문서를 미리 작성하여 끊임없이 변화하는 요구 사항을 수정하는 것은 효과가 없습니다 . 대신, 보다 민첩한 접근 방식으로 나아가는 것이 좋습니다, 사용자에게 빈번한 소프트웨어 릴리스 및 데모와 실제로 원하는 것에 대한 많은 토론이 있습니다. 사용자는 언제든지 요구 사항에 대해 마음을 바꿀 권리가 있지만 각 변경에는 비용과 시간이 소요됩니다. 개발자는 각 변경 요청에 대한 비용을 추정 할 수 있으므로 사용자 / 제품 소유자가 정보에 근거한 결정을 내릴 수 있습니다. "확실히,이 기능 변경은 좋을 것입니다 ... 그러나이 다른 중요한 기능의 릴리스를 지연시키고 비용이 많이 든다면 지금 백 로그에 넣도록하겠습니다."

사용자가 승인 테스트 사례를 정의하고 테스트 데이터를 작성하도록하는 것이 더 많은 참여를 유도하고 사용자와 개발자 간의 상호 신뢰를 구축하는 좋은 방법입니다. 이를 통해 양 당사자는 구체적이고 측정 가능하며 테스트 가능한 수용 기준에 집중하고 유스 케이스를 일반적인 것보다 훨씬 자세하게 생각해야합니다. 결과적으로 사용자는 각 릴리스를 통해 현재 개발 상태를 직접 확인할 수 있으며 개발자는 프로젝트 상태에 대한보다 구체적이고 확실한 측정 피드백을 얻을 수 있습니다. 그러나이를 위해서는 사용자의 헌신과 새로운 운영 방식이 필요하며 이는 받아들이고 배우기가 힘든 일입니다.

전환에 대한 나의 경험

몇 년 동안 나는 코드에 대한 단위 테스트를 작성하기에 충분한 시간이 없다는 오해를 받고 있었다. 테스트를했을 때, 그들은 부풀어 오르고 무거운 것들이 필요하다는 것을 알았을 때 단위 테스트를 작성해야한다고 생각하게 만들었 습니다 .

최근에 저는 테스트 주도 개발 을 사용하도록 권장 받았으며 완전한 계시라고 생각했습니다. 나는 이제 단위 테스트를 쓰지 않을 시간이 없다고 확신합니다 .

내 경험상 테스트를 염두에두고 개발하면 더 깨끗한 인터페이스, 더 집중된 클래스 및 모듈 및 일반적으로 더 많은 테스트 가능한 SOLID 코드가 생깁니다.

단위 테스트가없고 수동으로 무언가를 테스트해야하는 레거시 코드로 작업 할 때마다 "이 코드에 이미 단위 테스트가있는 경우 훨씬 빠를 것"이라고 계속 생각합니다. 높은 커플 링으로 코드에 단위 테스트 기능을 추가하려고 할 때마다 "이것이 분리 된 방식으로 작성된 경우 훨씬 쉬울 것"이라고 계속 생각합니다.

내가 지원하는 두 개의 실험 스테이션을 비교하고 대조합니다. 하나는 잠시 동안 있었고 많은 레거시 코드를 가지고 있지만 다른 하나는 비교적 새롭습니다.

이전 랩에 기능을 추가 할 때 랩으로 내려 가서 필요한 기능의 의미와 다른 기능에 영향을주지 않고 해당 기능을 추가하는 방법을 통해 많은 시간을 소비하는 경우가 종종 있습니다. 코드는 단순히 오프라인 테스트를 허용하도록 설정되지 않았으므로 거의 모든 것이 온라인으로 개발되어야합니다. 오프라인으로 개발하려고한다면 합리적인 것보다 더 많은 모의 객체 가 생길 것입니다.

최신 랩에서는 일반적으로 책상에서 오프라인으로 개발하여 즉시 필요한 항목 만 조롱 한 다음 실험실에서 짧은 시간 만 보내서 해결되지 않은 나머지 문제를 해결함으로써 기능을 추가 할 수 있습니다. -선.

나의 충고

개발 워크 플로를 크게 변경할 때마다 모든 사람 이 의사 결정에 참여하고 이상적으로는 대부분의 사람들이 구매 한 것으로 확인해야합니다. 당신의 질문에서, 당신이 이것을 가지고있는 것처럼 보입니다. 사람들이 아이디어에 대한 열정이 없다면 실패하거나 나쁜 의지를 만들어내는 것이 운명입니다.

매력적인 비즈니스 사례를 제시 할 수 없다면 전체 시스템에 대한 단위 테스트 및 사양의 기본 구현을 권장 하지 않습니다 . 위에서 언급했듯이 시스템이 테스트를 염두에두고 설계 되지 않은 경우 자동화 된 테스트를 작성하기가 매우 어려울 수 있습니다.

대신 소규모로 시작하고 보이 스카우트 규칙을 사용하는 것이 좋습니다 .

항상 캠프장을 찾은 것보다 깨끗하게 두십시오.

이 코드베이스에서 무언가를 구현하는 동안 기존 동작을 테스트하고 이전 동작에서 새로운 동작으로 전환하는 데 필요한 특정 테스트를 식별 할 수있는 경우 사양 변경을 문서화하고에 대한 단위 테스트 구현을 시작했습니다. 당신의 시스템.

손대지 않는 모듈은 단위 테스트를받지 않지만, 손대지 않으면 모듈은 이미 철저히 테스트 중이며 변경이 필요하지 않거나 사용되지 않았기 때문일 수 있습니다.

피하고 싶은 것은 결코 필요하지 않은 테스트를 작성하는 데 많은 개발자 노력을 낭비하는 것입니다 ( YAGNI 는 생산 코드 * 8 '와 마찬가지로 테스트 코드에서도 작동합니다). 테스트는 결국 쓸모 없다고 생각했습니다.

요약

소규모로 시작하여 점진적으로 테스트에 대한 신뢰를 구축하고 팀에 가장 유리한시기와 장소에서 테스트를 개발하여 비즈니스 가치를 얻으십시오.

가장 먼저해야 할 일은 테스트가 아니라 전체 프로세스를 올바르게하는 것입니다. 해야 할 일을 완전히 이해하지 못하면 아무 것도 테스트하지 않아도됩니다!

.. 먼저 사양 및 변경되지 않은 문서화 된 사양 (잘 아는 것은 아님). 당신이 그 일을하는 것을 봐야합니다. 사용자가 사양을 업로드하거나 직접 입력 할 수있는 웹 사이트를 추천합니다. 버그 트래커 및 프로젝트 진행에 대한 가이드에 링크 할 수도 있습니다.

그게 당신이 정말로 필요한 전부입니다. 내부적으로 단위 테스트를 추가 할 수 있으며 관리자는 개발자가 단위 테스트를 수행하고 있음을 알 필요가 없습니다. 어떤 식 으로든, 그것이 예상되는 방식입니다.

여전히 시스템 테스트를 수행해야하지만 프로젝트 관리 웹 사이트에 연결될 수 있으며, 일단 릴리스되면 테스트 팀 (다른 운 좋은 개발자 인 경우에도 해당)은 테스트 팀을 통해 테스트했는지 업데이트 할 수 있습니다. 모든 것이 함께 매달려 있습니다.

솔직히 말해서 이것이 입소문을내는 데 익숙하다면 전투가 거의 완전히이 행동을 바꿀 것입니다. 그리고 당신은 이것에 저항 할 것입니다. "그냥 x 만해라"라고 말하고 익숙해지지 않은 사용자 (또는 BA 또는 PM 또는 누구든지)는 잘 응답하지 않을 것입니다. 입소문 업데이트. 따라서 단위 테스트를 잊고 개발 수명주기에서 큰 문제를 시작하십시오.

첫 번째 문제 : "개발자에게 테스트 데이터 및 단위 테스트 세트를 제공하려면"먼저 개발자의 직무 인 단위 테스트를 작성해야합니다. 단위 테스트는 사양을 대체하지 않습니다. 사양은 단위 테스트보다 높은 추상화 레벨을 갖도록 고안되었습니다.

두 번째 문제 : 최대 단위 테스트 범위를 원하는 것 같습니다. 이 경우 요구 사항이 지속적으로 변하는 상황에서 테스트와 코드를 작성하는 데 시간과 돈이 너무 많이 듭니다. 대신 코드의 어떤 부분이 중요한지 결정하고 해당 부분 만 단위 테스트합니다. 많은 경우 변경되는 요구 사항이 제품의 중요한 부분에 영향을 미치지 않습니다. 고객 (또는 CEO 또는 기타)은 일반적으로이 패널을 오른쪽으로 이동하거나 제목의 색상을 빨간색에서 녹색으로 변경하도록 요청합니다. 반면 고객은 해시 알고리즘을 SHA512에서 SHA256으로 변경하거나 세션 저장 방식을 변경하도록 요구하지 않을 것입니다. 가장 많은 테스트가 필요한 부분입니다.