Kiểm soát phiên bản và TDD

Tôi hiện đang tìm hiểu về TDD và cố gắng đưa nó vào thực tế trong các dự án cá nhân của tôi. Tôi cũng đã sử dụng kiểm soát phiên bản rộng rãi cho nhiều dự án này. Tôi quan tâm đến sự tương tác của hai công cụ này trong một quy trình công việc điển hình, đặc biệt là khi nói đến câu châm ngôn để giữ cho các cam kết nhỏ. Dưới đây là một số ví dụ xuất hiện trong tâm trí:

1. Tôi bắt đầu một dự án mới và viết một bài kiểm tra đơn giản để tạo ra một lớp chưa tồn tại. Tôi có nên thực hiện bài kiểm tra trước khi viết lớp mặc dù bài kiểm tra thậm chí không biên dịch? Hoặc tôi nên bỏ ra số lượng mã tối thiểu cần thiết để có được bài kiểm tra biên dịch trước khi cam kết?

2. Tôi tìm thấy một lỗi và viết một bài kiểm tra để tạo lại nó. Tôi có nên cam kết kiểm tra không thành công hoặc thực hiện sửa lỗi và sau đó cam kết không?

Đây là hai ví dụ xuất hiện trong tâm trí ngay lập tức. Hãy cung cấp các ví dụ bổ sung trong câu trả lời của bạn.

Chỉnh sửa:

Tôi đã đưa ra một giả định trong cả hai ví dụ rằng ngay sau khi viết bài kiểm tra tôi sẽ viết mã để thực hiện bài kiểm tra. Một tình huống khác cũng có thể xảy ra: Tôi làm việc trên một dự án sử dụng TDD trong vài giờ mà không cam kết. Cuối cùng khi tôi thực hiện cam kết, tôi muốn chia nhỏ công việc của mình thành những phần nhỏ. (Git làm điều này tương đối dễ dàng ngay cả khi bạn muốn chỉ cam kết một số thay đổi trong một tệp.)

Điều này có nghĩa là câu hỏi của tôi cũng nhiều như những gì cần cam kết cũng như khi nào nên cam kết.

Tôi có nên thực hiện bài kiểm tra trước khi viết lớp mặc dù bài kiểm tra thậm chí không biên dịch? Hoặc tôi nên bỏ ra số lượng mã tối thiểu cần thiết để có được bài kiểm tra biên dịch trước khi cam kết?

Tất nhiên là không. Bạn nên hoàn thành cả bài kiểm tra và lớp học. Cam kết một cái gì đó ¹ mà thậm chí không biên dịch làm cho không có ý nghĩa, và chắc chắn sẽ làm cho mọi người làm việc trên cùng một dự án nổi giận nếu bạn làm điều đó thường xuyên.

Tôi tìm thấy một lỗi và viết một bài kiểm tra để tạo lại nó. Tôi có nên cam kết kiểm tra không thành công hoặc thực hiện sửa lỗi và sau đó cam kết không?

Không, không cam kết một bài kiểm tra thất bại. Luật LeBlanc quy định:

Sau này không bao giờ bằng.

và bài kiểm tra của bạn có thể thất bại trong một thời gian dài. Nó là tốt hơn để khắc phục vấn đề ngay khi nó được phát hiện.

Ngoài ra, phong cách phát triển TDD cho biết:

Phát triển dựa trên thử nghiệm liên tục lặp lại các bước thêm các trường hợp thử nghiệm thất bại, vượt qua chúng và tái cấu trúc.

Nếu bạn kiểm tra trong một bài kiểm tra thất bại, điều đó có nghĩa là bạn đã không hoàn thành chu trình.

¹ Khi tôi nói cam kết, tôi có nghĩa là thực sự cam kết với trung kế (đối với người dùng git, hãy thúc đẩy các thay đổi của bạn, để các nhà phát triển khác sẽ có được chúng).

Tôi có nên thực hiện bài kiểm tra trước khi viết lớp mặc dù bài kiểm tra thậm chí không biên dịch?

Không.

Tôi có nên thực hiện bài kiểm tra thất bại

Không.

Bạn đang nói về hai mô hình ở đây:

1. kiểm tra hướng phát triển - không nói gì về việc cam kết mã. Thật vậy, nó cho bạn biết về cách viết mã và khi bạn hoàn thành. Vì vậy, tôi coi mọi 'việc' là một ứng cử viên cho một cam kết.
2. phát triển nhanh, cụ thể: "cam kết sớm và thường xuyên" (không yêu cầu TDD). Ý tưởng đằng sau nó là tích hợp sớm với các thành phần khác trong hệ thống và do đó nhận được phản hồi sớm. Nếu bạn cam kết trong một DVCS tại địa phương và không thúc ép, điều đó có nghĩa là vô ích. Cam kết địa phương chỉ giúp các nhà phát triển cấu trúc công việc của họ.

Đề xuất của tôi là: theo vòng tròn TDD cho đến khi mã của bạn biên dịch, các bài kiểm tra của bạn có màu xanh và bạn có một cái gì đó để đóng góp cho hệ thống. Do đó, bạn nên cắt các tính năng của mình theo chiều dọc, ví dụ: đối với mặt nạ UI mới, đừng tạo toàn bộ biểu mẫu và cam kết mà không có logic nghiệp vụ, mà chỉ thực hiện một khía cạnh nhỏ nhưng ở mặt trước cũng như logic nghiệp vụ cũng như trong lớp kiên trì .

Đối với một lỗi lớn, hãy cam kết sau mỗi lần cải tiến (ví dụ: tái cấu trúc), ngay cả khi lỗi chưa được sửa. Các thử nghiệm phải có màu xanh và mã phải được biên dịch.

Chắc chắn bạn bắt đầu với việc sử dụng kiểm soát nguồn lành mạnh như git.

Sau đó, bạn có thể làm việc theo cách bạn thích và cam kết ở mỗi góc - bất kỳ bước hoặc bước phụ là một trò chơi công bằng.

Sau đó, trước khi đẩy các công cụ bạn ép toàn bộ công việc vào một cam kết duy nhất. Hoặc một cặp vợ chồng, tại các điểm mà mọi thứ đều có màu xanh lá cây và bố cục có ý nghĩa. Và đẩy những cam kết hợp lý. Đối với nhiều trường hợp, hãy đặt nó thành một nhánh mà bạn hợp nhất với --no-ff.

Kiểm soát nguồn không phải là một hệ thống theo dõi công việc hoặc sử gia. Các cam kết sẽ trình bày một delta đồng nhất hợp lý, trong khi trạng thái thanh toán sẽ được biên dịch ít nhất. Các trung gian có thể được bảo tồn trong một thời gian cho mục đích đánh giá, nhưng một khi mọi thứ được coi là ổn, một cam kết duy nhất cho mỗi tính năng là công bằng.

Theo hiểu biết của tôi về thế giới, người ta cam kết đánh dấu một điểm mà nó có thể mong muốn quay trở lại. Điểm mà một bài kiểm tra thất bại (nhưng biên dịch) chắc chắn là một điểm như vậy. Nếu tôi đi lang thang sai hướng khi cố gắng vượt qua bài kiểm tra, tôi sẽ muốn có thể hoàn nguyên mã trở lại điểm bắt đầu và thử lại; Tôi không thể làm điều này nếu tôi không cam kết.

Tôi có nên thực hiện bài kiểm tra trước khi viết lớp mặc dù bài kiểm tra thậm chí không biên dịch?

Với một SCM phân nhánh (tôi thấy bạn sử dụng Git), bạn nên cam kết bất cứ khi nào bạn muốn một điểm sao lưu ("Tôi đã làm hỏng một cái gì đó; tôi sẽ đặt lại thư mục làm việc về điểm sao lưu cuối cùng") hoặc khi bạn có phiên bản ổn định. Khi bạn có một phiên bản ổn định (tất cả các thử nghiệm vượt qua), bạn cũng nên xem xét việc hợp nhất nhánh tính năng hiện tại vào nhánh phát triển chính của mình.

Hoặc tôi nên bỏ ra số lượng mã tối thiểu cần thiết để có được bài kiểm tra biên dịch trước khi cam kết?

Tùy thuộc vào bạn (git cho phép bạn linh hoạt cam kết bất cứ khi nào bạn muốn mà không ảnh hưởng đến các thành viên khác trong nhóm của bạn hoặc khả năng làm việc trên các tính năng khác nhau). Chỉ cần đảm bảo rằng bạn không có nhiều tính năng không hoàn chỉnh (không hoạt động) trong cùng một nhánh (sau đó chúng sẽ chặn nhau).

Tôi tìm thấy một lỗi và viết một bài kiểm tra để tạo lại nó. Tôi có nên cam kết kiểm tra không thành công hoặc thực hiện sửa lỗi và sau đó cam kết không?

Tôi thường thực hiện hai cam kết cho điều đó, trừ khi mã kiểm tra thực sự nhỏ / tầm thường để viết.

Đây là hai ví dụ xuất hiện trong tâm trí ngay lập tức. Hãy cung cấp các ví dụ bổ sung trong câu trả lời của bạn.

Chỉnh sửa:

Tôi đã đưa ra một giả định trong cả hai ví dụ rằng ngay sau khi viết bài kiểm tra tôi sẽ viết mã để thực hiện bài kiểm tra.

Đó có thể là một giả định sai để thực hiện. Nếu bạn làm việc một mình (dự án cá nhân), không có gì ngăn cản bạn luôn làm điều đó. Trong một trong những dự án thành công nhất của tôi (liên quan đến việc duy trì chất lượng mã cao và TDD trong suốt quá trình phát triển dự án), chúng tôi đã xác định các thử nghiệm đôi khi vài tuần trước khi thực hiện chúng (tức là chúng tôi sẽ nói "kiểm tra" test_FOO_with_null_first_parameter "hiện được xác định là một hàm trống và cam kết như vậy). Sau đó, chúng tôi sẽ chạy nước rút (hoặc nửa lần chạy nước rút) đôi khi một tháng hoặc lâu hơn, để tăng phạm vi kiểm tra cho mô-đun. Vì chúng tôi đã kiểm tra rất dễ ước tính.

Một tình huống khác cũng có thể xảy ra: Tôi làm việc trên một dự án sử dụng TDD trong vài giờ mà không cam kết. Cuối cùng khi tôi thực hiện cam kết, tôi muốn chia nhỏ công việc của mình thành những phần nhỏ. (Git làm cho việc này tương đối dễ dàng ngay cả khi bạn chỉ muốn thực hiện một số thay đổi trong một tệp.) Điều này có nghĩa là câu hỏi của tôi cũng giống như những gì cần cam kết khi thực hiện.

Tôi chắc chắn sẽ cam kết tạo điểm dự phòng . Điều này hoạt động rất tốt cho thử nghiệm khám phá ("Tôi sẽ chỉ thêm một số bản in trong toàn bộ cơ sở mã, chạy và git reset --hardxóa chúng khi tôi hoàn thành) và để tạo mẫu.

Trong quy trình làm việc của tôi, bất cứ khi nào có thể tôi đều làm việc không chắc chắn trên một nhánh kiểm soát nguồn cá nhân. Vì vậy, tôi có thể thử, thất bại, thử lại nếu cần thiết cho đến khi nó hoạt động và chỉ cam kết với dự án lớn hơn khi tôi có mã làm việc thực tế.

Từ góc độ TDD, câu hỏi "bạn có đăng ký kiểm tra trước không?" hoàn toàn phụ thuộc vào mã mà bạn đang làm việc. Nếu đó là mã mới, bạn không đăng ký bất cứ điều gì cho đến khi bạn có thứ gì đó đáng để đăng ký. Nhưng nếu đó là một lỗi được tìm thấy trong mã đã được biên dịch hoặc vận chuyển, thì việc kiểm tra để kiểm tra lại lỗi, BỞI ITSELF, đáng để kiểm tra. Đặc biệt nếu đó là kết thúc một ngày làm việc và bạn sẽ rời khỏi văn phòng trước khi sửa mật mã.

(Tất nhiên, nếu cửa hàng của bạn có quy trình xây dựng tự động bị chết nếu bất kỳ bài kiểm tra đơn vị nào thất bại, bạn có thể không muốn kiểm tra lỗi cho đến khi bạn sửa lỗi. Nhưng đó có vẻ là một cách kỳ lạ để làm việc, vì "tìm và lỗi tài liệu "và" sửa lỗi "có thể được thực hiện bởi hai nhóm hoàn toàn khác nhau.)