TDD는 복잡한 프로젝트에서 실제로 작동합니까?

TDD 프로젝트에서 경험 한 문제에 대해이 질문을하고 있습니다. 단위 테스트를 만들 때 다음과 같은 문제를 발견했습니다.

• 모의 데이터 생성 및 유지

대규모 모의 데이터를 유지 관리하는 것은 어렵고 비현실적입니다. 데이터베이스 구조가 변경 될 때 더욱 어려워집니다.

• GUI 테스트

MVVM과 GUI 테스트 기능이 있더라도 GUI 시나리오를 재현하려면 많은 코드가 필요합니다.

• 사업 테스트

간단한 비즈니스 로직으로 제한하면 TDD가 잘 작동한다는 경험이 있습니다. 그러나 테스트 조합 (테스트 공간)의 수가 매우 많기 때문에 복잡한 비즈니스 로직을 테스트하기가 어렵습니다.

• 요구 사항의 모순

실제로 분석 및 설계중인 모든 요구 사항을 파악하기는 어렵습니다. 프로젝트가 복잡하기 때문에 한 번의 참고 요구 사항으로 인해 모순이 발생하는 경우가 많습니다. 모순은 구현 단계에서 늦게 발견됩니다. TDD는 요구 사항이 100 % 정확해야합니다. 이러한 경우 테스트 작성 중에 충돌하는 요구 사항이 캡처 될 것으로 예상 할 수 있습니다. 그러나 문제는 복잡한 시나리오에서는 그렇지 않다는 것입니다.

이 질문을 읽었습니다. 왜 TDD가 작동합니까?

TDD는 복잡한 엔터프라이즈 프로젝트에서 실제로 작동합니까, 아니면 실제로 프로젝트 유형으로 제한됩니까?

대규모 모의 데이터를 유지 관리하는 것은 어렵고 비현실적입니다. 데이터베이스 구조가 변경 될 때 더욱 어려워집니다.

그릇된.

단위 테스트에는 "대형"모의 데이터가 필요하지 않습니다. 시나리오를 테스트하기에 충분한 모의 데이터가 필요합니다.

또한 진정으로 게으른 프로그래머는 주제 전문가에게 다양한 테스트 사례의 간단한 스프레드 시트를 작성하도록 요청합니다. 간단한 스프레드 시트입니다.

그런 다음 게으른 프로그래머는 간단한 스크립트를 작성하여 스프레드 시트 행을 단위 테스트 사례로 변환합니다. 정말 간단합니다.

제품이 발전하면 테스트 케이스의 스프레드 시트가 업데이트되고 새 단위 테스트가 생성됩니다. 항상하세요. 이것은 진짜 작동한다.

MVVM과 GUI 테스트 기능이 있어도 GUI 시나리오를 재현하려면 많은 코드가 필요합니다.

뭐? "낳다"?

TDD의 요점은 테스트 가능성 (테스트 드라이브 개발)을위한 것을 디자인하는 것입니다. GUI가 그렇게 복잡한 경우 더 단순하고 테스트 가능하도록 재 설계해야합니다. 또한 단순할수록 더 빠르고 유지 관리가 쉽고 유연합니다. 그러나 대부분 단순할수록 테스트 가능성이 높아집니다.

간단한 비즈니스 로직으로 제한하면 TDD가 잘 작동한다는 경험이 있습니다. 그러나 테스트 조합 (테스트 공간)의 수가 매우 많기 때문에 복잡한 비즈니스 로직을 테스트하기가 어렵습니다.

사실 일 수 있습니다.

그러나 주제 전문가에게 핵심 테스트 사례를 간단한 형식 (예 : 스프레드 시트)으로 제공하도록 요청하면 실제로 도움이됩니다.

스프레드 시트가 다소 커질 수 있습니다. 그러나 간단한 Python 스크립트를 사용하여 스프레드 시트를 테스트 사례로 변환했기 때문에 괜찮습니다.

과. 스프레드 시트가 불완전하기 때문에 일부 테스트 사례를 수동으로 작성해야했습니다.

하나. 사용자가 "버그"를보고했을 때 스프레드 시트에서 어떤 테스트 사례가 잘못되었는지 간단히 물었습니다.

이때 주제 전문가는 스프레드 시트를 수정하거나 발생할 수있는 내용을 설명하는 예를 추가합니다. 대부분의 경우 버그 보고서를 테스트 사례 문제로 명확하게 정의 할 수 있습니다. 사실, 내 경험상 버그를 깨진 테스트 사례로 정의하면 토론이 훨씬 간단 해집니다.

전문가의 의견을 경청하기보다는 복잡한 복잡한 비즈니스 프로세스를 설명하려고 시도하기보다는 프로세스의 구체적인 예를 작성해야합니다.

TDD는 요구 사항이 100 % 정확해야합니다. 이러한 경우 테스트 작성 중에 충돌하는 요구 사항이 캡처 될 것으로 예상 할 수 있습니다. 그러나 문제는 복잡한 시나리오에서는 그렇지 않다는 것입니다.

TDD를 사용하지 않으면 요구 사항이 100 % 정확해야합니다. 일부는 TDD가 불완전하고 변화하는 요구 사항을 견딜 수 있다고 주장하는데, 비 TDD 접근 방식은 불완전한 요구 사항으로는 작동하지 않습니다.

TDD를 사용하지 않으면 구현 단계에서 늦게 모순이 발견됩니다.

TDD를 사용 하면 코드가 일부 테스트를 통과하고 다른 테스트에 실패 할 때 모순이 더 일찍 발견 됩니다. 실제로 TDD는 구현하기 훨씬 전에 프로세스 초기에 모순의 증거 를 제공합니다 (사용자 승인 테스트 중 인수).

일부 테스트를 통과하고 다른 테스트에 실패하는 코드가 있습니다. 그 시험 들만 보고 모순을 찾으십시오. 사용자가 모순에 대해 논쟁하고 원하는 행동의 일관되고 구체적인 예를 만들어야하기 때문에 실제로 실제로 실제로 잘 작동합니다.

예

TDD에 대한 첫 노출은 Linux 기반 휴대 전화 용 미들웨어 구성 요소에서 작업하는 것이 었습니다. 결국 수백만 줄의 소스 코드가 만들어졌으며, 다양한 오픈 소스 구성 요소에 대해 약 9 기가 바이트의 소스 코드가 필요했습니다.

모든 구성 요소 작성자는 API와 일련의 단위 테스트를 모두 제안하고 동료위원회에서 설계 검토를 받아야합니다. 완벽한 테스트를 기대 한 사람은 없었지만 공개적으로 노출 된 모든 기능에는 최소한 하나 이상의 테스트가 필요했으며, 구성 요소를 소스 제어에 제출 한 후에는 모든 구성 요소 테스트가 항상 통과해야했습니다 (구성 요소가 잘못보고 되었더라도 그렇게하더라도) 잘 작동했습니다).

의심의 여지없이 TDD와 모든 단위 테스트가 항상 통과해야한다는 주장으로 인해 1.0 릴리스는 초기에 예산이 책정되었으며 놀라운 안정성을 제공했습니다.

1.0 릴리스 이후, 기업은 고객 요구로 인해 범위를 빠르게 변경할 수 있기를 원했기 때문에 TDD 수행을 중단하고 단위 테스트 통과 요구 사항을 제거했습니다. 화장실의 질이 얼마나 빨리 떨어졌는가는 놀랍고 일정이 뒤따 랐습니다.

프로젝트가 복잡할수록 TDD를 통해 더 많은 혜택을 얻을 수 있다고 주장합니다. 주요 이점은 TDD가 코드를 훨씬 더 작고 독립적 인 덩어리로 작성하도록하는 방법의 부작용입니다. 주요 이점은 다음과 같습니다.

a) 시작 테스트로 인해 피드백 루프가 훨씬 빡빡하기 때문에 훨씬 더 일찍 디자인을 검증 할 수 있습니다.

b) 비트와 조각을 변경할 수 있으며, 전체 테스트 범위의 이불을 구축했기 때문에 시스템이 어떻게 반응하는지 확인할 수 있습니다.

c) 완성 된 코드는 결과적으로 훨씬 나을 것이다.

TDD는 복잡한 프로젝트에서 실제로 작동합니까?
예. 내가 들었던 모든 프로젝트가 TDD와 잘 작동하는 것은 아니지만 대부분의 비즈니스 응용 프로그램은 훌륭하며 순수한 TDD 방식으로 작성되었을 때 제대로 작동하지 않는 프로젝트는 큰 문제없이 ATDD 방식으로 작성할 수 있습니다.

모의 데이터 생성 및 유지 관리 데이터를
작게 유지하고 필요한 것만 가져야하며 이것이 무서운 문제는 아닙니다. 나를 잘못 이해하지 마라, 그것은 고통이다. 그러나 가치가 있습니다.

GUI
테스트 MVVM을 테스트하고보기없이 테스트 할 수 있는지 확인하십시오. 나는 다른 비즈니스 로직을 테스트하는 것보다 더 어렵지 않다는 것을 알았습니다. 내가하지 않는 코드로보기 테스트, 당신이 테스트하는 모든 것은이 시점에서 바인딩 로직입니다. 빠른 수동 테스트를 수행하면 빨리 잡힐 수 있기를 바랍니다.

비즈니스 테스트
문제가 아닙니다. 많은 작은 테스트. 위에서 말했듯이, 일부 경우 (Sudoku 퍼즐 솔버가 인기있는 것으로 보입니다)는 TDD를 수행하기가 어렵습니다.

TDD는 요구 사항이 100 % 정확해야합니다
. 그렇지 않습니다. 이 아이디어는 어디서 얻었습니까? 모든 애자일 관행은 요구 사항 변경을 수용합니다. 수행하기 전에 수행중인 작업을 알아야하지만 요구 사항을 100 %로 요구하는 것과는 다릅니다. TDD는 Scrum의 일반적인 관행이며, 요구 사항 (사용자 사례)은 100 % 완전하지는 않습니다.

우선, 귀하의 문제는 TDD보다 일반적으로 단위 테스트에 관한 것이라 생각합니다. 왜냐하면 귀하의 말에 실제로 TDD 관련 (테스트 우선 + 적 녹색 리 팩터 사이클)이 없기 때문입니다.

대규모 모의 데이터를 유지 관리하는 것은 어렵고 비현실적입니다.

모의 데이터 란 무엇을 의미합니까? 모의는 거의 모든 데이터를 포함하지 않아야합니다. 즉, 테스트에 필요한 하나 또는 두 개 이외의 필드는없고 테스트중인 시스템 이외의 종속성은 없습니다. 모의 기대 또는 반환 값을 설정하는 것은 한 줄로 수행 할 수 있으므로 끔찍한 일은 없습니다.

데이터베이스 구조가 변경 될 때 더욱 어려워집니다.

객체 모델을 적절히 수정하지 않고 데이터베이스가 변경되었다는 것을 의미하는 경우, 잘 테스트하기 위해 단위 테스트를 정확하게 수행합니다. 그렇지 않으면 모델 변경 사항이 단위 테스트에 분명히 반영되어야하지만 컴파일 표시를 사용하면 쉽게 수행 할 수 있습니다.

MVVM과 GUI 테스트 기능이 있더라도 GUI 시나리오를 재현하려면 많은 코드가 필요합니다.

맞습니다. GUI (View)의 단위 테스트는 쉽지 않으며 많은 사람들이 GUI 없이도 잘 수행하고 있습니다 (GUI 테스트는 TDD의 일부가 아닙니다). 반대로 Controller / Presenter / ViewModel / 중간 계층을 단위 테스트하는 것이 좋습니다. 실제로 MVC 또는 MVVM과 같은 패턴이있는 주된 이유 중 하나입니다.

간단한 비즈니스 로직으로 제한하면 TDD가 잘 작동한다는 경험이 있습니다. 그러나 테스트 조합 (테스트 공간)의 수가 매우 많기 때문에 복잡한 비즈니스 로직을 테스트하기가 어렵습니다.

비즈니스 로직이 복잡한 경우 일반적으로 단위 테스트를 설계하기 어렵다. 각 테스트 대상 개체에 대해 하나의 책임 만 테스트하여 가능한 한 원자 적으로 만드는 것은 사용자의 몫입니다. 단위 테스트는 코드를 변경할 때 비즈니스 규칙이나 요구 사항을 위반하지 않도록 보장하는 보안 네트워크를 제공하므로 복잡한 환경에서 더 많이 필요합니다.

TDD는 요구 사항이 100 % 정확해야합니다.

절대적으로하지. 성공적인 소프트웨어는 요구 사항이 100 % 정확해야합니다.) 단위 테스트는 현재 요구 사항에 대한 비전이 무엇인지를 반영합니다. 비전에 결함이있는 경우 코드와 소프트웨어도 단위 테스트 여부에 관계없이 단위 테스트가 빛을 발하는 곳 : 테스트 제목이 충분히 명시 적이면 디자인 결정 및 요구 사항 해석이 투명 해져서보다 쉽게 ​​지적 할 수 있습니다. 다음 번에 고객이 "이 비즈니스 규칙은 내가 원하는 것과는 다릅니다."

TDD를 사용하여 응용 프로그램을 테스트 할 수없는 이유는 응용 프로그램이 너무 복잡하기 때문에 누군가가 불평한다고 들었을 때 웃어야합니다. 대안은 무엇입니까? 테스트 원숭이가 에이커의 키보드를 두드리고 있습니까? 사용자가 테스터가되게 하시겠습니까? 또 뭐요? 물론 어렵고 복잡합니다. 인텔은 출하 될 때까지 칩을 테스트하지 않는다고 생각하십니까? 그 "모래"는 어떻습니까?

복잡한 이유, 소설 및 / 또는 퍼지 알고리즘과 같은 관련 이유로 TDD (및 일반적으로 단위 테스트)가 사실상 불가능하다는 것을 알았습니다. 필자가 작성한 연구 프로토 타입에서 가장 많이 발생하는 문제는 코드를 실행하는 것 외에 올바른 답변이 무엇인지 전혀 모른다는 것입니다. 아주 사소한 경우를 제외하고는 손으로 합리적으로 파악하기가 너무 복잡합니다. 알고리즘에 휴리스틱, 근사 또는 비결 정성이 포함 된 경우 특히 그렇습니다. 나는 여전히이 코드가 의존하는 하위 수준의 기능을 테스트하려고 시도하고 온 전성 검사로 강력하게 주장합니다. 나의 마지막 수단 테스트 방법은 두 개의 서로 다른 라이브러리 세트를 사용하여 두 개의 서로 다른 언어로 이상적인 두 가지 구현을 작성하고 결과를 비교하는 것입니다.

> Does TDD really work for complex projects?

내 경험으로는 : 예를 들어 (Gui, Mvvm, Business-Modell)과 같은 문제가 없기 때문에 Unittests ( 단독 으로 모듈 / 기능 테스트)에 대해 그렇습니다 . 한 번의 단위 테스트를 완료하기 위해 3 개 이상의 모의 / 스텁이 없었습니다 (그러나 도메인에 더 많은 것이 필요할 수 있습니다).

그러나 TDD가 BDD 스타일 테스트 와 의 통합 또는 엔드 투 엔드 테스트 에서 언급 한 문제를 해결할 수 있는지 확실하지 않습니다 .

그러나 최소한 몇 가지 문제를 줄일 수 있습니다 .

> However complex business logic is hard to test since the number 
> of combinations of tests (test space) is very large.

통합 테스트 또는 엔드 투 엔드 테스트 레벨에서 전체 적용 범위를 수행하려는 경우에 해당됩니다. 단위 테스트 수준에서 전체 범위를 다루는 것이 더 쉬울 수 있습니다.

예 : 복잡한 사용자 권한 확인

IsAllowedToEditCusterData()통합 테스트 레벨 에서 기능 을 테스트하려면 사용자, 도메인, 고객, 환경에 대한 정보를 다른 오브젝트에 요청해야합니다.

이 부분들을 조롱하는 것은 상당히 어렵다. IsAllowedToEditCusterData()이러한 다른 객체를 알아야 할 경우 특히 그렇습니다 .

Unittest-Level IsAllowedToEditCusterData()에는 함수가 알아야 할 모든 것을 포함하는 20 개의 매개 변수를받는 함수가 있습니다. 이후 IsAllowedToEditCusterData()필드 것을 알 필요가 없다 user하는 domain하는 customer, ...이 테스트하기 쉬운 있습니다.

구현해야 할 때 IsAllowedToEditCusterData()두 가지 과부하가 발생했습니다.

20 개의 매개 변수를 얻은 다음 의사 결정을 수행하는 20 개의 매개 변수로 오버로드를 호출하는 것 이상을 수행하지 않는 하나의 과부하.

(내 IsAllowedToEditCusterData()매개 변수는 5 개 뿐이며 완전히 테스트하려면 32 가지 조합이 필요했습니다)

예

// method used by businesslogic
// difficuilt to test because you have to construct
// many dependant objects for the test
public boolean IsAllowedToEditCusterData() {
    Employee employee = getCurrentEmployee();
    Department employeeDepartment = employee.getDepartment();
    Customer customer = getCustomer();
    Shop shop = customer.getShop();

    // many more objects where the permittions depend on

    return IsAllowedToEditCusterData(
            employee.getAge(),
            employeeDepartment.getName(),
            shop.getName(),
            ...
        );
}

// method used by junittests
// much more easy to test because only primitives
// and no internal state is needed
public static boolean IsAllowedToEditCusterData(
        int employeeAge,
        String employeeDepartmentName,
        String shopName,
        ... ) 
{
    boolean isAllowed; 
    // logic goes here

    return isAllowed;
}

슬픈 대답은 대규모 복잡한 프로젝트에는 아무런 효과가 없다는 것입니다!

TDD는 다른 것만 큼 좋고 대부분의 것보다 낫지 만 TDD만으로는 큰 프로젝트에서 성공을 보장하지는 않습니다. 그러나 성공 가능성이 높아집니다. 특히 다른 프로젝트 관리 분야 (요구 사항 확인, 사용 사례, 요구 사항 관리도 매트릭스, 코드 연습 등)와 함께 사용하는 경우.

단위 테스트는 사양 이 적용됨을 기억하십시오 . 이것은 복잡한 프로젝트에서 특히 중요합니다. 이전 코드베이스에 백업 테스트가 없으면 아무것도 깨뜨리는 것을 두려워하기 때문에 아무도 아무것도 바꾸지 않을 것입니다.

"Wtf. 왜이 코드 브랜치가 존재 하는가? 모르는 것, 누군가가 그것을 필요로하고, 누군가를 화나게하는 것보다 그곳에 남겨 두는 것이 좋다 ..."복잡한 프로젝트는 시간이 지남에 따라 쓰레기의 땅이된다.

테스트를 통해 누구나 "나는 급격한 변화를 겪었지만 모든 테스트는 여전히 진행 중"이라고 자신있게 말할 수 있습니다. 정의상 그는 아무것도 부수 지 않았다. 이것은 더 민첩한 프로젝트로 이어질 수 있습니다. 코볼을 유지하기 위해 사람들이 여전히 필요한 이유 중 하나는 테스트가 그 이후로 인기가 없었기 때문입니다. : P

TDD가 독점적으로 사용되었을 때, 즉 최소한 디버거 / IDE에서 설정하지 않으면 큰 복잡한 프로젝트가 완전히 실패하는 것을 보았습니다. 모의 데이터 및 / 또는 테스트가 불충분 한 것으로 판명되었습니다. 베타 클라이언트의 실제 데이터는 민감하여 복사하거나 기록 할 수 없습니다. 따라서 개발자 팀은 실제 데이터를 가리킬 때 나타나는 치명적인 버그를 절대 수정할 수 없었으며 전체 프로젝트가 폐기되고 모든 사람이 해고되었습니다.

이 문제를 해결하는 방법은 클라이언트 사이트의 디버거에서 문제를 해결하고 실제 데이터에 대해 실시간으로 코드를 단계별로 중단 점, 감시 변수, 감시 메모리 등과 함께 실행하는 것이 었습니다. 거의 1 년 동안 아이보리 타워를 장식하기에 적합하다고 생각한 사람은 거의 1 년 동안 앱을 실행 한 적이 없었습니다. 그건 내 마음을 날려 버렸다.

따라서 모든 것과 마찬가지로 균형이 핵심입니다. TDD는 좋지만 독점적으로 의존하지는 않습니다.

그렇게 생각합니다. 테스트 주도 개발이 실제로 작동하는 것을보십시오.

2008 년 Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat 및 Laurie Williams는 “테스트 중심 개발을 통한 품질 개선 현실화 : 4 개의 산업 팀의 결과 및 경험” (PDF 링크) 이라는 논문을 썼습니다 . 초록 :

TDD (Test-driven development)는 수십 년 동안 산발적으로 사용 된 소프트웨어 개발 사례입니다. 이 연습을 통해 소프트웨어 엔지니어는 실패한 단위 테스트 작성과 구현 테스트 작성 사이에서 분 단위로 순환하여 해당 테스트를 통과합니다. 테스트 중심 개발은 최근 민첩한 소프트웨어 개발 방법론의 중요한 구현 사례로 다시 등장했습니다. 그러나 산업적 맥락에서이 관행의 유용성을지지하거나 반박하는 경험적 증거는 거의 없다. 사례 연구는 Microsoft의 3 개 개발 팀과 TDD를 채택한 IBM의 한 개발 팀에서 수행되었습니다. 사례 연구의 결과는 4 가지 제품의 시험판 결함 밀도가 TDD 사례를 사용하지 않은 유사한 프로젝트에 비해 40 %에서 90 % 사이로 감소했음을 나타냅니다. 주관적으로

2012 년에 Ruby on Rails 개발 사례는 TDD를 가정합니다. 필자는 개인적으로 테스트 및 모의 작성을위한 rspec, 객체 생성을위한 factory_girl, 브라우저 자동화를위한 capybara, 코드 적용을위한 simplecov 및 이러한 테스트 자동화를위한 보호 도구와 같은 도구를 사용합니다.

이 방법론과 도구를 사용한 결과 Nagappan et al.

예산, 요구 사항 및 팀 기술의 조합이 프로젝트 공간의 사분면에 '여기에 들어가는 모든 사람들을 희망하지 말라'고 정의하면 프로젝트가 실패 할 가능성이 압도적으로 높습니다.

아마도 요구 사항이 복잡하고 변동이 심하거나 인프라가 불안정하거나 팀 중학교 및 이직률이 높거나 건축가가 바보 일 수 있습니다.

TDD 프로젝트에서이 임박한 실패의 증상은 스케줄에 따라 테스트를 작성할 수 없다는 것입니다. 당신은 단지 발견하는 시도 '걸릴 거예요 그 이 긴, 그리고 우리는이 것을 '.

다른 접근 방식은 실패 할 때 다른 증상을 나타냅니다. 작동하지 않는 시스템을 가장 일반적으로 제공합니다. 정치와 계약은 그것이 바람직한 지 결정합니다.

TDD처음에는 고통으로 들릴지 모르지만 장기적으로는 가장 친한 친구가 될 것 TDD입니다. 장기적으로 응용 프로그램을 유지 관리하고 안전하게 만들 수 있다고 믿습니다 .