2010-01-21 24 views
38

Tôi đang cố gắng quyết định xem có nên sử dụng Cuke4Nuke hay SpecFlow không. Ưu điểm/nhược điểm của mỗi loại là gì? Ý kiến ​​trên đó là tốt hơn và tại sao.Cuke4Nuke hoặc SpecFlow?

Cảm ơn!

Trả lời

58

(Tôi có thể bị sai lệch bởi vì tôi tham gia với SpecFlow, nhưng ở đây suy nghĩ của tôi ...)

Cuke4Nuke rất gần với dưa chuột. này hứa hẹn rất nhiều lợi thế:

  • Compatibility
  • Bắt tính năng mới từ dưa chuột khi tiến hóa Dưa chuột (ít nhất là về mặt lý thuyết, nhưng hỗ trợ ngôn ngữ là một ví dụ cho việc này)
  • Là một phần thực sự của cộng đồng dưa chuột và dưa chuột hệ sinh thái

Tuy nhiên điều này cũng đi kèm với một số nhược điểm tiềm năng:

  • Ruby là điều cần thiết
  • Vì có thêm cơ sở hạ tầng (Ruby, Wire-Protocol, tích hợp dòng lệnh ...), sự phức tạp của toàn bộ giải pháp tăng lên và cơ hội trong chuỗi không tăng
  • Gỡ lỗi là có thể nhưng một chút của một hassle
  • Chạy kịch bản trên lệnh dos chỉ đơn giản là xấu xí và tôi vẫn gặp sự cố với một số ký tự (tiếng Đức Umlaute). Các solutions từ dưa chuột không làm việc cho cuke4nuke trong trường hợp của tôi.
  • Tích hợp với xây dựng liên tục của bạn là một cái gì đó bạn phải làm việc ra cho chính mình

SpecFlow là một dự án riêng biệt từ dưa chuột. Nó cố gắng càng gần Cucumber càng tốt, nhưng có và sẽ có những khoảng trống. Có những kế hoạch sử dụng cùng một trình phân tích cú pháp như Cucumber, để cải thiện khả năng tương thích ở cấp độ ngôn ngữ.

SpecFlow cố gắng cung cấp những ưu điểm sau:

  • Một giải pháp NET tinh khiết (vì vậy không cần cài đặt của Ruby là cần thiết và Ruby là không tham gia trong thời gian chạy)
  • Có một tích hợp cơ bản với VisualStudio (và có kế hoạch để phát triển điều này)
  • Các trường hợp về cơ bản là UnitTests và có thể chạy với cơ sở hạ tầng hiện có của bạn (NUnit.Runners, ReSharper, VisualStudio MSTest Integration ...)
  • Các kịch bản và các bước có thể dễ dàng gỡ lỗi ra khỏi VisualStud io (chỉ cần thiết lập một breakpoint)
  • Tích hợp trong xây dựng liên tục của bạn phải là một làn gió, kể từ khi cơ sở hạ tầng để chạy đơn vị xét nghiệm chắc chắn là hầu hết đã có

Như nhược điểm của SpecFlow Tôi hiện thấy:

  • Nó không hỗ trợ nhiều ngôn ngữ như Cucumber
  • Hiện tại có một bước "tạo mã" tham gia.Đây là minh bạch khi sử dụng VisualStudio, và có một dòng lệnh để làm điều này mà không có VisualStudio, nhưng rất nhiều người không thích tạo mã.
  • Hiện tại không có nhân vật dòng lệnh rõ ràng nào cho SpecFlow. Tuy nhiên bạn có thể sử dụng nhân vật dòng lệnh thử nghiệm đơn vị của bạn.
  • SpecFlow phụ thuộc vào khuôn khổ Đơn vị kiểm tra và hiện tại chỉ NUnit và MSTest được hỗ trợ
  • Báo cáo trong SpecFlow chưa quá phức tạp. Dưa chuột cung cấp nhiều lựa chọn hơn, tuy nhiên tôi không biết nếu chúng có sẵn trong cuke4nuke ...
+1

Cảm ơn bạn đã có thông tin chi tiết tuyệt vời. Tôi là một nhà phát triển .NET nên dựa trên các ý kiến ​​của bạn, tôi sẽ thử Specflow ngay bây giờ. –

+0

Tôi cũng đánh giá cao ý kiến ​​của bạn, jbandi. Tôi đã thực hiện một bình luận tương tự trên một bài khác trong đó khả năng chạy thử nghiệm SpecFlow của tôi trong ReSharper (giống như bất kỳ thử nghiệm NUnit khác) là một lợi thế rất thực tế hơn Cuke4Nuke. Không cài đặt Ruby là một cái khác (sau khi tất cả chúng ta phải giữ cho máy chủ xây dựng được cập nhật và đó là một điều nữa phải lo lắng). –

+0

Trên tàu, .. tuyệt vời chạy xuống jb. Đã xóa hoàn toàn lựa chọn này cho tôi. Bây giờ tôi vừa thuyết phục người quản lý. :-) – Stimul8d

11

jbandi đưa ra một bản tóm tắt tốt. Tôi trả lời câu hỏi theo cùng một cách (với tuyên bố từ chối trách nhiệm đối với thiên vị, dĩ nhiên).

Mục tiêu cho Cuke4Nuke là tương thích đầy đủ Dưa chuột trong .NET khi sao chép ít mã Cucumber nhất có thể. Do đó, một số sự cân bằng mà bạn đã đánh dấu — ví dụ: sự phụ thuộc của Ruby - vốn vốn có của công cụ. Những người khác, như lỗi trong ngôn ngữ và hỗ trợ định dạng và hỗ trợ gỡ lỗi giới hạn, là các vấn đề tạm thời và sẽ biến mất cùng với các phiên bản trong tương lai.

Tôi đã gặp phải một vài vấn đề mà Cuke4Nuke không hoạt động giống như Cucumber. Nhưng khi tôi làm việc chủ yếu bằng tiếng Anh, tôi không thấy các vấn đề liên quan đến ngôn ngữ trong công việc bình thường của mình. Tôi hoan nghênh các bước để tái tạo bất kỳ vấn đề nào trong số những vấn đề này để tôi có thể khắc phục chúng. (Xin vui lòng gửi cho họ the Cuke4Nuke issues list, không ở đây.)

11

Một ý kiến ​​rất nhiều thành kiến: Cố gắng StoryQ :)

kiểm tra StoryQ thực sự là mã, do đó bạn sẽ có được sự ủng hộ refactoring/IDE tốt hơn nhiều, và nó nhúng trong hiện tại của bạn Á hậu thử nghiệm đơn vị, do đó, CI là một khoe.

Đây có thể là vấn đề ưu tiên bạn có muốn kiểm tra các tính năng văn bản thuần túy hoặc mã có thể biên dịch hay không. Nhưng đối với chúng tôi, chúng tôi thấy rằng thật tuyệt khi có thể đổi tên các phương thức tường thuật và tự cập nhật tất cả các câu chuyện. Có một GUI được cung cấp để chuyển đổi các kịch bản thuần văn bản thành mã StoryQ cho bạn, nếu bạn đã đầu tư vào các kịch bản rõ ràng hoặc nếu bạn muốn cung cấp bàn phím cho những người kinh doanh của mình. Nó thậm chí còn có một hình thức đơn giản của intellisense!

Give it một đi nếu bạn muốn có một điểm vào siêu nhẹ vào BDD :)

+0

Tôi rất hài lòng với cách thức dễ dàng StoryQ được dựng và chạy. Tuy nhiên, tôi chưa thử text-> code GUI. –

+0

@david cảm ơn! Các văn bản để mã gui là để giúp bạn bắt đầu, hoặc mang những người phi kỹ thuật trên tàu. Mục đích là cuối cùng bạn vẫn duy trì các tệp C# và tôi chỉ sử dụng API. –

7

Một phản ứng sai lệch: StorEvil ngốn tất cả các công cụ .NET BDD khác.

Ưu điểm: StorEvil có nhân vật dòng lệnh riêng, có báo cáo đẹp (sử dụng công cụ xem Spark), và có bản dịch tốt nhất - C# và công cụ thực thi.

Ngoài ra, nó còn có nhiều hơn 100% so với bất kỳ giải pháp nào khác.

Nhược điểm: StorEvil không hỗ trợ đầy đủ các ngôn ngữ khác của con người (trừ tiếng Anh). Tích hợp Visual Studio của StorEvil vẫn chưa tốt bằng các công cụ khác. StorEvil sẽ uống tất cả bia trong tủ lạnh nếu bạn không để ý đến nó.

+0

Có vẻ thú vị. vẫn còn hoạt động trong dự án? –

6

tôi bắt đầu với Cuke4Nuke nhưng kể từ khi đào thoát sang SpecFlow (xin lỗi Richard ;-)

Những lý do chính cho tôi để thực hiện chuyển đổi đó là:

  • SpecFlow có tích hợp VS2010 tốt đẹp cho làm nổi bật cú pháp của Tính năng, đặc điểm. Có một dự án Cuke4VS cung cấp tương tự nhưng nó không có hỗ trợ VS2010 (hoặc không phải khi tôi nhìn cuối cùng, mà là khá gần đây)
  • Tôi tìm thấy các thử nghiệm gỡ lỗi trong SpecFlow để dễ dàng hơn (đừng hỏi tôi để xây dựng, nó chỉ có vẻ như vậy ... ;-)
  • Cuke4Nuke cần Ruby. Tôi đã đồng ý với điều đó nhưng hầu hết các nhà phát triển C# mà tôi biết đều bị bất ngờ bởi bất kỳ sản phẩm nào không phải của MS, đặc biệt là Ruby.

Có một số vấn đề với Specflow/điều tôi thích tốt hơn trong thế giới dưa chuột/Cuke4Nuke:

  • tài liệu Specflow là khá 'lite' - bạn sẽ phải được chuẩn bị để làm việc chăm chỉ để thu thập thông tin từ nguồn Cucumber và intuit một chút cách chúng áp dụng cho Specflow. Điều đó nói rằng bản thân tôi và vài người khác có thiết kế trên tăng cường tài liệu để có thể cải thiện trong vài tháng tới.
  • Tôi thích trải nghiệm chạy thử nghiệm Cucumber/Cuke4Nuke trên dòng lệnh với đầu ra của các kịch bản mã màu theo trạng thái (tôi biết ai đó ở trên coi đây là âm tính vì vậy tôi đoán nó phụ thuộc vào việc bạn là một lệnh line line of guy ...)
  • Cộng đồng Dưa chuột lớn hơn và có nhiều hoạt động hơn mà dường như (có thể) dịch cho nhiều người hơn ở đó để giúp bạn.

Tất cả trong cả hai đều có khả năng cải thiện cách chúng tôi viết phần mềm.

7

Tôi hiểu từ Richard rằng ông dự định sẽ ngừng Cuke4Nuke và đang hỗ trợ di chuyển một số tính năng Cuk4Nuke vào SpecFlow. Vì vậy, câu trả lời rõ ràng bây giờ là SpecFlow.

+0

[cần dẫn nguồn] –

+2

Vì không ai khác cung cấp trích dẫn, tôi sẽ: https://github.com/richardlawrence/Cuke4Nuke/wiki –

Các vấn đề liên quan