Có ai đang thực hiện các chương trình TDD thực tế với Visual-C ++ không, và nếu có, họ làm điều đó như thế nào? [đóng cửa]

Test Driven Development ngụ ý viết thử nghiệm trước mã và theo một chu kỳ nhất định :

• Kiểm tra viết
• Kiểm tra kiểm tra (chạy)
• Viết mã sản xuất
• Kiểm tra kiểm tra (chạy)
• Làm sạch mã sản xuất
• Kiểm tra kiểm tra (chạy)

Theo như tôi quan tâm, điều này chỉ có thể nếu giải pháp phát triển của bạn cho phép bạn chuyển đổi rất nhanh giữa mã sản xuất và mã thử nghiệm và thực hiện thử nghiệm cho một phần mã sản xuất nhất định cực kỳ nhanh chóng.

Bây giờ, trong khi tồn tại rất nhiều Khung kiểm tra đơn vị cho C ++ (Tôi đang sử dụng Bost.Test atm.) Dường như không thực sự tồn tại bất kỳ giải pháp Visual Studio (Plugin C ++ ) nào tạo ra TDD chu kỳ chịu được bất kể khuôn khổ được sử dụng.

"Có thể chịu được" có nghĩa là hành động chỉ bằng một cú nhấp chuột để chạy thử nghiệm cho một tệp cpp nhất định mà không phải thiết lập thủ công dự án thử nghiệm riêng biệt, v.v. "Có thể chịu được" cũng có nghĩa là thử nghiệm đơn giản bắt đầu (liên kết!) Và chạy rất nhanh .

Vậy, những công cụ (plugin) và kỹ thuật nào hiện có giúp chu trình TDD có thể phát triển C ++ bản địa với Visual Studio?

Lưu ý: Tôi ổn với các công cụ miễn phí hoặc "thương mại".

Xin vui lòng : Không có khuyến nghị khung. (Trừ khi khung có plugin Visual Studio chuyên dụng và bạn muốn giới thiệu plugin.)

Chỉnh sửa Lưu ý : Các câu trả lời cho đến nay đã cung cấp các liên kết về cách tích hợp khung Kiểm tra đơn vị vào Visual Studio. Các tài nguyên ít nhiều mô tả cách lấy khung UT để biên dịch và chạy thử nghiệm đầu tiên của bạn. Đây không phải là những gì câu hỏi này là về. Tôi cho rằng để thực sự làm việc hiệu quả, có các Bài kiểm tra đơn vị được bảo trì thủ công (!), Vcproj riêng biệt khỏi các lớp sản xuất của bạn sẽ thêm rất nhiều chi phí mà TDD "không thể thực hiện được". Theo như tôi biết, bạn không thêm các "dự án" bổ sung vào thứ Java hoặc C # để kích hoạt Bài kiểm tra đơn vị và TDD và vì một lý do chính đáng. Điều này nên có thể với C ++ được cung cấp đúng công cụ, nhưng có vẻ như (câu hỏi này là về) có rất ít công cụ cho TDD / C ++ / VS.

Googling xung quanh, tôi đã tìm thấy một công cụ, VisualAssert , dường như nhằm đi đúng hướng. Tuy nhiên, afaiks, nó dường như không được sử dụng rộng rãi (so với CppUnit, Boost.Test, v.v.).

Chỉnh sửa: Tôi muốn thêm một nhận xét cho bối cảnh cho câu hỏi này. Tôi nghĩ rằng đó là một bản tóm tắt tốt về phác thảo (một phần) vấn đề: (bình luận của Billy ONeal )

Visual Studio không sử dụng "tập lệnh xây dựng" mà người dùng có thể chỉnh sửa hợp lý. Một dự án tạo ra một nhị phân. Hơn nữa, Java có thuộc tính mà Java không bao giờ xây dựng một nhị phân hoàn chỉnh - nhị phân mà bạn xây dựng chỉ là một ZIP của các tệp lớp. Do đó, có thể biên dịch riêng sau đó JAR với nhau theo cách thủ công (sử dụng ví dụ 7z). Cả C ++ và C # đều thực sự liên kết các nhị phân của chúng, vì vậy nói chung bạn không thể viết một tập lệnh như thế. Cách gần nhất bạn có thể nhận được là biên dịch mọi thứ riêng biệt và sau đó thực hiện hai liên kết (một để sản xuất, một để thử nghiệm).

Tôi đã viết một loạt blog gồm 5 phần về làm TDD với C ++ và Visual Studio: phần 1 , phần 2 , phần 3 , phần 4 , phần 5 .

Tôi không chắc tại sao bạn nói rằng bạn không thực hiện các dự án bổ sung trong C # để làm TDD, bởi vì đó là điều tôi luôn làm với NUnit và có vẻ như đó là những gì người khác làm với NUnit. Lý do rất đơn giản: luôn giữ mã kiểm tra tách biệt với mã sản xuất. Đối với C ++ với Visual Studio, điều này có nghĩa là các dự án riêng biệt giống như với C # và NUnit. Từ những gì tôi biết về thế giới Java, điều này cũng phổ biến ở đó.

Rõ ràng, mọi người đều có những ý tưởng khác nhau về những gì "có thể chịu được" khi làm TDD. Tôi đã thực hành phương pháp tôi phác thảo trong bài viết trên blog của mình trong nhiều năm và tôi thấy nó rất có thể chịu được. C ++ là một ngôn ngữ được biên dịch và các công cụ biên dịch có thể bị chậm khi hệ thống được thử nghiệm được kết hợp chặt chẽ. Không có bất cứ điều gì thoát khỏi điều đó mà không tái cấu trúc thành một thiết kế ghép lỏng lẻo hơn.

"Hành động một lần nhấp" của tôi là "Giải pháp xây dựng". Nếu việc xây dựng quá nhiều, bạn luôn có thể dỡ các dự án không liên quan trong khi bạn đang làm việc và sau đó Build Solution sẽ chỉ xây dựng tập hợp con tối thiểu của các dự án được cập nhật do những thay đổi của bạn.

Được cho phép, bản chất thời gian biên dịch của C ++ khiến việc này mất nhiều thời gian hơn trong mỗi chu trình của quy trình TDD so với NUnit và C #, nhưng sự tự tin mà tôi có được từ mã C ++ được kiểm tra tốt của tôi là xứng đáng. Nếu không, tôi sẽ dành nhiều thời gian hơn cho trình gỡ lỗi. Tôi sẽ thận trọng khi sử dụng gmock vì bạn có thể thêm đáng kể để kiểm tra thời gian biên dịch. Cho đến nay tôi hầu như đã thoát khỏi những vật thể "giả" nhẹ và hiếm khi cần chức năng toàn diện của giả. Các khung mô phỏng cho C ++ dựa trên khuôn mẫu rất nhiều và điều này có thể tăng thời gian biên dịch đáng kể, vì vậy chúng nên được dành riêng cho nơi bạn thực sự cần một bản giả và một bản giả sẽ không làm.

Tôi đã xem xét việc tạo một trình hướng dẫn dự án thử nghiệm đơn vị Boost.Test để tự động hóa một số tính chất của tấm nồi hơi trong việc tạo dự án thử nghiệm cho mã sản xuất, nhưng sau khi bạn thực hiện nó một vài lần thì thực sự không khó để làm thủ công.

Đối với các giải pháp với nhiều dự án (150?), Cũng có nhiều cách để đối phó với điều đó. Một điều hiển nhiên là tìm các nhóm dự án liên quan và kết hợp chúng lại với nhau và bắt đầu tiêu thụ chúng / xuất bản chúng dưới dạng một đơn vị. Nếu bạn thực sự cần phải xây dựng lại / chạm vào tất cả 150 dự án cho những thay đổi nhỏ mà bạn đang thực hiện trong chu kỳ TDD, thì mã của bạn sẽ được kết hợp rất cao dù sao các thử nghiệm đơn vị không có khả năng tạo ra sự khác biệt.

Nhìn vào liên kết IDE của netbeans, tôi thấy mắt có một cái gì đó phân tích cú pháp đầu ra thử nghiệm và hiển thị một hàng thử nghiệm nhỏ trong một cửa sổ có biểu tượng màu xanh lá cây hoặc màu đỏ bên cạnh nó một cái gì đó mà tôi nghĩ rằng tôi sẽ bỏ lỡ từ NUnit, nhưng không thực sự bỏ lỡ. Tôi thấy nó hữu ích hơn cho việc xây dựng chỉ đơn giản là thất bại và sau đó tôi có thể nhấp đúp vào cửa sổ lỗi để đặt con trỏ tại vị trí của xác nhận thất bại.

Tôi không sử dụng Visual-C ++, nhưng tôi đang thực hiện TDD với C ++, sử dụng googletest và googlemock, với QtCreator làm IDE của tôi. Cách đây nhiều năm, tôi đã có một thiết lập tương tự với Visual-C ++ nhưng sử dụng khung kiểm tra đơn vị khác.

Những gì tôi thấy hữu ích là tách dự án thành một vài tiểu dự án.

1. Một thư viện tĩnh hoặc động chứa 99% mã nguồn dự án thực tế.
2. Một dự án bao gồm chủ yếu là một phương thức main () để chạy chương trình bình thường.
3. Một dự án thử nghiệm có chứa một hàm main () để chạy khung thử nghiệm của tôi và rất nhiều tệp chứa các đối tượng thử nghiệm và giả định.

Với thiết lập này, IDE của tôi đảm nhiệm việc thêm tệp vào các dự án khác nhau và nếu phụ thuộc được xác định chính xác, tôi có thể chạy tất cả các thử nghiệm đơn vị của mình với việc xây dựng lại một phần. Tôi thậm chí còn có nó hiện đang thiết lập để chạy tất cả các thử nghiệm của mình ngay sau khi tôi xây dựng. Jenkins, CI tôi hiện đang sử dụng, cũng chạy và cung cấp kết quả kiểm tra và dữ liệu bảo hiểm.

Có thể thêm một trình khởi chạy tùy chỉnh trong IDE của bạn cho một tệp để chạy thử nghiệm đơn vị cho tệp Foo.cpp nếu bạn tình cờ đặt tên cho tất cả các thử nghiệm đơn vị cho Foo theo lịch thi thử TestFoo. Cách thiết lập chính xác cho Visual-C ++ Tôi không chắc nhưng tôi nghĩ nó có thể.

Tôi sử dụng MSTest để kiểm tra mã C ++ bản địa.
Đây là bài đăng blog tuyệt vời về cách này: http://blogs.msdn.com/b/jsocha/archive/2010/11/19/writer-unit-tests-in-visual-studio-for-native-c. aspx

Vâng, sẽ có ít nhất hai dự án - một cho chính ứng dụng, một cho các thử nghiệm.
Thay vì tạo dự án thứ ba với thư viện tĩnh, tôi chỉ cần thêm nguồn của ứng dụng vào dự án thử nghiệm, vì vậy giải pháp trông như thế này:

[-] Solution 'Foo'      Foo\Foo.sln
 |-[-] Foo              Foo\Foo\Foo.vcproj
 |  |-[-] include
 |  |  |- foo.h         Foo\Foo\foo.h
 |  |  |- bar.h         Foo\Foo\bar.h
 |  |
 |  |-[-] source
 |     |- foo.cpp       Foo\Foo\foo.cpp
 |
 |-[-] Foo.Tests        Foo\Foo.Tests\Foo.Tests.vcproj
    |                        (Additional include directory: "..\Foo")
    |-[-] include
    |  |- FakeBar.h     Foo\Foo.Tests\FakeBar.h
    |
    |-[-] source
       |-[-] app
       |  |- foo.cpp    Foo\Foo\foo.cpp    -- not in Foo.Tests\
       |
       |-[-] unit-tests
          |- foo_Tests.cpp   Foo\Foo.Tests\foo_Tests.cpp
          |- bar_Tests.cpp   Foo\Foo.Tests\bar_Tests.cpp

Có thể hơi muộn trong ngày, nhưng nếu tôi đọc chính xác câu hỏi của bạn, bạn đang tìm kiếm các kỹ thuật để cải thiện chu trình TDD? Nó không được đề cập ở đây, nhưng bạn đã xem các sự kiện hậu xây dựng trong VS chưa?

Các giải pháp của chúng tôi thường được tổ chức (với Phụ thuộc dự án được hiển thị) ...

MAIN-APP > LIB1, LIB2, UNIT-TEST-APP
UNIT-TEST-LIB1 > LIB1
UNIT-TEST-LIB2 > LIB2
UNIT-TEST-APP > UNIT-TEST-LIB1, UNIT-TEST-LIB2

Sự kiện hậu xây dựng của MAIN-APP sẽ chạy UNIT-TEST-APP

Sự kiện hậu xây dựng của UNIT-TEST-APP sẽ tự chạy (chỉ cần đặt '$ (TargetPath)' làm lệnh để chạy trong sự kiện hậu xây dựng).

(Điều này không có nghĩa là khi xây dựng MAIN-APP, các bài kiểm tra đơn vị có thể chạy hai lần, nhưng đó không thực sự là vấn đề trong trường hợp của chúng tôi!)

Như đã đề cập, vâng, có một chút nỗ lực trong việc thiết lập cấu trúc này, nhưng một khi đã có, việc thêm các bài kiểm tra rất đơn giản.

Vì vậy, tất cả những gì bạn phải làm là xây dựng ứng dụng chính và các bài kiểm tra đơn vị sẽ tự động chạy!

Chà, không biết điều này có giúp ích gì không, nhưng có một số video tuyệt vời về TDD từ Brett L. Schuchert. Thật không may, anh ta không hiển thị kết hợp "C ++" và "VS", nhưng

TDD với C # và VS: http://vimeo.com/album/210446

TDD với C ++ và Eclipse: http://vimeo.com/13240481

Có lẽ bạn có thể làm việc đó từ hai.

EDIT: video C ++ nói về việc sử dụng khung hình thử nghiệm CppUTest với Eclipse, tất nhiên. Khi tôi đăng nó, tôi nghĩ rằng nó nên được chấp nhận dễ dàng để sử dụng trong VS. Vì vậy, tôi đã googled một chút và tìm thấy điều này:

http://schuchert.wikispaces.com/tdd.cpp.NotesOnCppUTest

cung cấp cho bạn thông tin về cách sử dụng CppUTest trong Visual Studio.

Googletest
Cách tích hợp với vc ++

Bạn không cần một plugin, bài kiểm tra chỉ là một mục tiêu khác. Không có plugin để tạo thử nghiệm với c ++, evne nếu bạn có thể thử nghiệm những thứ vô nghĩa như bài tập

Không thể nhận xét về các công cụ C ++ vì tôi đã không chạm vào trong khoảng 20 năm (.NET dev những ngày này) và tôi đoán hầu hết các công cụ ngày nay là dành cho mã được quản lý nhưng đối với kỹ thuật ...

Như những người khác đã đề cập, mã kiểm thử luôn nằm trong một dự án / lắp ráp hoàn toàn khác với mã sản xuất và vâng, bạn thường phải tự duy trì dự án đó, mặc dù chắc chắn trong VS IDE, đây không phải là vấn đề lớn vì bạn thường có một số dự án như một phần của giải pháp của bạn nào.

Mã sản xuất là và phải được viết một chút khác biệt cho TDD. Khi bạn viết các bài kiểm tra trước tiên, bạn sẽ phải thiết kế mã của mình để có thể kiểm tra được. Bản thân nó là toàn bộ chủ đề khác nhưng có thể mất thời gian và có vẻ rất bực bội, đặc biệt là nếu IDE / công cụ của bạn không cung cấp cho bạn thông tin phản hồi nhanh, tách ra để chạy các công cụ dòng lệnh để chạy thử nghiệm chỉ là để phá vỡ.

Có rất nhiều kỹ thuật cụ thể để tạo mã có thể kiểm tra được, nhưng hầu hết trong số chúng phân tích để tạo ra các đối tượng nhỏ không làm được gì nhiều để bạn có thể kiểm tra chúng một cách riêng lẻ và có thể đưa phiên bản thử nghiệm của một số hành vi vào phức tạp hơn các đối tượng. Khung IOC có thể giúp rất nhiều ở đây.

Một cuốn sách bạn có thể thấy hữu ích là; Michael Feathers, làm việc hiệu quả với Bộ luật kế thừa. Điều này sử dụng nhiều ngôn ngữ trong các ví dụ của nó và có thể giúp bạn xác định các phương pháp cụ thể để mã / kỹ thuật thích ứng an toàn mà ban đầu không được thiết kế để có thể kiểm tra được.

Nhắc nhở nhỏ: Tôi say rượu từ Agile Kool-Aid năm trước: D

Maven không được sử dụng rộng rãi trong C ++ (tuy nhiên, nó chủ yếu được sử dụng cho Java nhưng không liên quan đến ngôn ngữ) nhưng nó là một công cụ rất mạnh và nó cho phép bạn giữ mọi thứ trong một dự án (bao gồm cả các thử nghiệm, trên thực tế, đó là khuyến nghị tiếp cận với Maven). Tôi chỉ đề xuất nó ngay từ khi có câu trả lời cho đến nay có vẻ như một giải pháp thay thế với plugin VS có thể không tồn tại.

Tìm kiếm các plugin tôi tìm thấy:

http://incubator.apache.org/npanday/

nhưng nó không có vẻ rất trưởng thành. Với thiết lập Maven, tất cả những gì bạn cần làm để chạy các bài kiểm tra được chạy mvn testtrong dòng lệnh.

Nếu bạn quan tâm, bạn có thể tìm hiểu về nó ở đây và (một trong) các plugin hỗ trợ C ++ tại đây (Maven có kiến ​​trúc plugin để mọi thứ đều là plugin).

Đề xuất khung: Tại văn phòng của chúng tôi, chúng tôi sử dụng TestDriven.NET tích hợp với Visual Studio. Các lớp không đáng tin cậy nhất được viết bằng C ++ / CLI, sau đó có thể gọi ra để thực hiện bất kỳ mã gốc nào bạn cần kiểm tra. Có, các lớp C ++ / CLI đi vào tổ hợp riêng của chúng, do đó, một dự án "thử nghiệm" được thêm vào (các) giải pháp.