TDD có khả thi trong các dự án nguồn mở hợp tác không

Giả sử tôi muốn bắt đầu một dự án nguồn mở mà tôi hy vọng / mong đợi sẽ có nhiều người gửi các bản vá và không có gì. Có khả thi để thực hiện một cách tiếp cận TDD nghiêm ngặt? Tôi có thể / nên mong đợi / tin tưởng các cộng tác viên viết bài kiểm tra chất lượng bất cứ khi nào họ gửi bản vá không?

Một điều tôi đã suy nghĩ là viết các bộ kiểm thử cho các báo cáo lỗi và yêu cầu tính năng riêng lẻ và yêu cầu tất cả các yêu cầu vá / kéo làm cho các thử nghiệm vượt qua, nhưng tại thời điểm đó, có vẻ tốt hơn là chỉ viết tính năng / sửa lỗi riêng tôi.

Theo như tôi có thể nói, hầu hết các dự án nguồn mở lớn sử dụng TDD (hoặc ít nhất là các bài kiểm tra viết) dường như hầu hết được viết bởi một cá nhân hoặc nhóm, nơi dễ thực thi các thực hành như TDD.

open-source tdd collaboration

— DormoTheNord
nguồn

Chia sẻ nghiên cứu của bạn giúp mọi người. Hãy cho chúng tôi những gì bạn đã cố gắng và tại sao nó không đáp ứng nhu cầu của bạn. Điều này chứng tỏ rằng bạn đã dành thời gian để cố gắng tự giúp mình, nó giúp chúng tôi tránh nhắc lại các câu trả lời rõ ràng và hầu hết nó giúp bạn có được câu trả lời cụ thể và phù hợp hơn. Xem thêm Cách hỏi

— gnat

@gnat Tôi đã tìm kiếm StackExchange và đã có một vài câu hỏi mà mọi người hỏi về các ví dụ về các dự án nguồn mở với các bài kiểm tra đơn vị, không giống như câu hỏi của tôi. Theo yêu cầu của bạn, tôi đã thêm một số thông tin.

— DormoTheNord

DormoTheNord Tôi tin rằng @gnat có nghĩa là các ví dụ cụ thể, được trích dẫn .

— haneefmubarak

"sẽ tốt hơn nếu chỉ tự viết tính năng / sửa lỗi." Có hay không có xét nghiệm? Bạn có phải là người đề xuất TDD hay chỉ kiểm tra xem liệu nó có khả thi trong bối cảnh này không?

— JeffO 19/12/13

Tất nhiên, bạn có thể / nên mong các cộng tác viên viết bài kiểm tra chất lượng bất cứ khi nào họ gửi bản vá. Điều đó không chỉ có lợi - nó cực kỳ phổ biến trong các dự án nguồn mở lớn hiện nay (tôi có thể đưa ra ví dụ nếu bạn muốn).

— Benjamin Gruenbaum

Câu trả lời:

Bạn thực sự không thể thực thi cách tiếp cận TDD (thử nghiệm đầu tiên) trên một dự án nguồn mở nơi mà các bản vá có thể được gửi bởi công chúng.

Những gì bạn có thể thực thi là tất cả các bản vá phải có một bộ các trường hợp kiểm thử cho các bản sửa lỗi có trong bản vá và các trường hợp kiểm thử đó, cũng như tất cả các trường hợp kiểm thử hiện có, phải vượt qua. Bạn có thể thực thi điều này bằng cách chỉ trao quyền cam kết cho một vài nhà phát triển đáng tin cậy đã biết sử dụng và đồng ý với các chính sách của dự án và bằng cách tuyên bố công khai rằng việc gửi / yêu cầu kéo sẽ chỉ được kết hợp nếu họ đi qua các trường hợp thử nghiệm (với bảo hiểm đầy đủ).

Điều này không đảm bảo rằng bài kiểm tra được viết trước , nhưng nó đảm bảo rằng bài kiểm tra được viết .

— Bart van Ingen Schenau
nguồn

Chắc chắn chủ sở hữu kho lưu trữ có thể từ chối để kéo bất kỳ thay đổi nào không phù hợp với tiêu chuẩn chất lượng của dự án? Có lẽ chất lượng và số lượng đóng góp sẽ bị ảnh hưởng nếu những người đóng góp không thích điều này, nhưng điều đó không có nghĩa là bạn không thể thực thi nó. Chắc chắn phải không?

— Tom W

@TomW: Làm thế nào bạn kiểm tra xem bài nộp của tôi được tạo theo thông lệ TDD và không, ví dụ, với các bài kiểm tra được viết sau khi thực hiện xong?

— Bart van Ingen Schenau 19/12/13

Ah, tôi hiểu ý của bạn. Tôi cho rằng một số mất mát nghiêm ngặt là không thể tránh khỏi, nhưng bạn vẫn có thể xác minh rằng mã đi kèm với các thử nghiệm, rằng các thử nghiệm có đủ chi tiết và chúng bao gồm mọi thứ mà chúng được cho là. Tôi không quen thuộc với git, nhưng đối với một yêu cầu kéo nhất định, có thể kiểm tra chuỗi cam kết cho các thay đổi đó để xem rằng nhà phát triển đã tuân theo một quy trình phù hợp để tạo ra nó không?

— Tom W

Nói cách khác, bạn không thể xác nhận quy trình nội bộ của một người, nhưng bạn có thể đảm bảo đầu ra của quy trình đó đáp ứng một tiêu chuẩn nhất định. Yêu cầu kiểm tra và đảm bảo thiết kế hợp lý nằm trong khả năng của chủ sở hữu.

— Adrian Schneider

Bạn có thể yêu cầu mọi người gửi các bản vá chỉ thử nghiệm trước khi họ được phép làm việc với mã; điều này sẽ cung cấp một cơ hội bổ sung để xem xét thiết kế theo kế hoạch trước khi bản thân mã được viết.

Trong thực tế, điều này có thể giết chết bất kỳ người nhiệt tình nào đã đóng góp cho dự án - hoặc nó có thể gây ra hỏa hoạn ở những người đồng ý với phương pháp của bạn.

Tuy nhiên, những người đánh giá sẽ phải rất giỏi trong việc xoay quanh các đánh giá thiết kế một cách nhanh chóng, để không cản trở sự phát triển.

— Alex Feinman
nguồn