TDD를 사용한 복잡한 코드의 좋은 예

37

크고 실제적인 복잡한 프로젝트에서 TDD를 사용하는 좋은 예는 무엇입니까? 지금까지 본 모든 사례는 책이나 종이를위한 장난감 프로젝트입니다 ...

TDD를 많이 사용하는 오픈 소스 프로젝트의 이름을 지정할 수 있습니까? 가급적 C ++에서는 Java와 C # 또는 다른 유사한 언어를 읽을 수 있습니다.

귀하의 질문에 대답하기가 어렵습니다. 자동화 된 테스트를 활용하는 많은 프로젝트가 있지만 TDD 철학을 얼마나 멀리 추진하고 있는지는 말하기가 어렵습니다. 또한 c ++, c # 및 java kinda는 GUI 응용 프로그램에 뿌리를두고 있으며 테스트하기가 어렵습니다. 일반적으로 프레임 워크 또는 라이브러리에서 더 많은 테스트를 찾을 수 있습니다.

— iMacUwhAK

내가 좋은 대답을 찾는 데 관심이있는 이유 중 하나는 현재 C ++ 엔진과 Java GUI를 사용하여 데스크탑 응용 프로그램에서 작업하고 있기 때문입니다.

— Xavier Nodet

TDD로 작성되고 테스트 적용 범위가 우수한 실제 사례의

— gnat

19

JUnit 은 100 % 테스트 중심으로 개발되었습니다. 실제로 JUnit에서 100 % 테스트 중심으로 개발되었으며 , Kent Beck이 말했듯이 몇 번은 정말 마음을 굽히는 운동이라고합니다.
나는 생각 썬 ZFS 파일 시스템 테스트 주도 개발되었다.
에 대한 ikj 인터프리터 Ioke의 언어 자체 프로그래밍 언어 (JVM)의 Ioke 프로그래밍 언어 (CLI), 전체 Ioke 코어와 표준 라이브러리의 IKC 통역, 실제로는 100 % 테스트 주도 (실제로는 행위 주도 개발 ).

— 요 르그 W 미타 그
소스

델파이의 테스트 프레임 워크 인 DUnit은 DUnit 자체를위한 완전한 테스트 모음을 제공합니다. 그리고 나는 Kent에 동의합니다. ;-)

— Nick Hodges

14

SQLite. 모든 코드는 매우 철저하게 테스트되었습니다 .

버전 3.7.14부터 SQLite 라이브러리는 약 81.3 KSLOC의 C 코드로 구성됩니다. (KSLOC는 수천 개의 "소스 라인 코드"또는 다른 말로 빈 줄과 주석을 제외한 코드 라인을 의미합니다.) 비교하면 프로젝트의 테스트 코드와 테스트 스크립트는 1124 배나 많습니다-91421.1 KSLOC.

— 리 오리
소스

1

와우, 그들은 많은 테스트를 가지고 있습니다 : |

— Luca Matteis

8

심하게 테스트되었다고해서 반드시 TDD (Test-driven) 방식으로 개발 된 것은 아닙니다. 그 것이었다? (전체 페이지를 읽지는 않았지만 인 페이지 검색에서 "TDD"나 "드라이브"를

— 보지 못했기

1

@lindes : TDD를 엄격하게 따르지 않는 것처럼 보이지만, 예를 들어 모든 버그 보고서에 대해 먼저 테스트를합니다. 또한 모든 커밋마다 테스트를 실행합니다. 적어도 부분적으로 이것은 TDD입니다.

— liori

9

FitNesse가 TDD로 작성되었고 프로젝트의 주요 기여자 인 Bob Martin 아저씨를 기억한다면 아마도 코드가 깨끗할 것입니다.

— CaffGeek
소스

난 그냥 한 번 봐 가지고, 그것은 이다 정말 깨끗한 코드입니다.

— Robert Harvey

3

Microsoft P & P 팀과의 토론에서 Enterprise Library는 TDD로 작성되었습니다.

— 월터
소스

Enterprise Library 5.0을 풀다운하고 소스 코드를 살펴 보았습니다. 광범위한 테스트 모음이 있지만 테스트 프로젝트에는 많은 테스트 픽스처, 콜 핸들러 및 기타 복잡한 개체가 있습니다. 그것은 거의 자체적으로 응용 프로그램처럼 보입니다. 나는 그 작품에 감탄하지만, 그것이 레드-그린-리 팩터의 TDD 세계관에 어떻게 적합한 지 알지 못한다.

— Robert Harvey

@Robert-나는 그들이 나에게 말한 것을 말할 수 있습니다 ... 그들은 그것을 쓸 때 TDD를 사용했습니다.

— Walter

6

@Robert-테스트 스위트가 자신의 삶을 취하는 것은 드문 일이 아닙니다. DRY는 응용 프로그램과 테스트 모두에 적용됩니다. TDD에서는 테스트 작성, 코드 작성, 리팩토링 테스트, 리팩토링 코드 중 하나만 수행합니다. 빨간색-녹색 리 팩터 패턴으로 이러한 모든 작업을 수행하는 경우 TDD를 수행하는 것입니다.

— Jeff Knecht

1

@ Jeff : 명확히 해주셔서 감사합니다. TDD가 설명되는 방식 (환원 론적, 기계적인 용어)과 실제 시나리오에서 실제로 사용되는 방식 사이에는 약간의 차이가 있다고 생각합니다.

— Robert Harvey

3

TDD를 사용한 오픈 소스 프로젝트의 이름을 지정할 수는 없지만 TDD가 사용 된 실제 프로젝트에서 작업했으며 생명의 은인이었다고 말할 수 있습니다!

— 스티븐 에이 로우
소스

1

당신이나 다른 사람들이 이러한 경험을 공유 했습니까? 좋은 전쟁 이야기처럼 들립니다.

나는 그것에 대해 조금 트윗하고 일화를 사용하여 다른 게시물의 요점을 설명했습니다. 테스트 우선 디자인과 자동화 된 테스트 스위트는 인생을 훨씬 더 쉽게 만들어서 돌아가서 다른 방법으로 개발하지 않을 것이라고 말하면 충분합니다. 예 : 한 테스트 사례에서 수동 테스트로는 찾지 못한 미묘한 버그 (수동 테스터는 모든 작업 후에 데이터베이스 무결성을 검사하지 않기 때문에); 이를 확인하기 위해 하루에 여러 번 테스트 케이스를 실행하여 40 시간 이상의 수동 테스트 시간을 절약했습니다. 최근에 잠자는 동안 1000 개 이상의 코드를 변경하고 테스트를 실행했습니다. TDD 락.

— Steven A. Lowe

당신을 믿어요 나는 그 이야기를 듣고 싶습니다. 당신은 QuickCheck의 재미를 찾을 수 있습니다 - en.wikipedia.org/wiki/QuickCheck을 - 나는 15 세 생산 코드에서 버그를 멀티 스레딩 발견 프리젠 테이션을 보았다.

"수동 테스터는 모든 작업 후 데이터베이스 무결성을 검사하지 않기 때문에"-제약 조건과 잘 설계된 DB 스키마는 더 많은 부분을 차지하며 버그를 즉시 보았을 때 하루 동안 테스트해야하는 모든 시간을 절약 할 수있었습니다. .

— gbjbaanb

@gbjbaanb :이 경우, '검사'그것을위한 자동화 된 테스트가있다 그 이유는, 간단한 스키마의 무결성보다 훨씬 더 복잡

— 스티븐 A. 로우에게

0

TDD에서 완전히 완료된 첫 번째 프로젝트는 2002 년 오픈 소스 프로젝트였습니다. 여전히 여기에서 찾을 수 있습니다.

http://sourceforge.net/projects/camelos/

이제 직장에서 나는 주로 TDD에서 일하고 있지만 우리 팀의 모든 사람이하는 것은 아닙니다. 마지막 날에 테스트를 썼다면 괜찮습니다.

또한 핵심 부분에 TDD를 사용하여 완전한 gwt-gae 응용 프로그램을 작성했습니다. http://netnumero.appengine.com/company/mycompany

해당 코드를 해제 할 수는 없지만 UI에서 TDD를 사용하는 GWT 용 TDD에서 수행 된 전체 예제 프로젝트를 진행하고 있습니다.

내가 끝내 자마자 (크리스마스 휴일) 나는 여기에 게시 할 것이다 https://github.com/ubertob/gwt-tdd-example

— 우 베르토
소스