Làm thế nào để đối phó với những người phá vỡ TDD?

Question

Cá nhân tôi thực sự thích Đơn vị kiểm tra và viết chúng cho vùng phủ sóng "tốt". (giả sử tôi cố gắng hết sức để viết các bài kiểm tra tốt;)

Như thường lệ, một số người khác cần thêm một số tính năng vào mã (thêm phương thức vào các lớp và vv). Ông không phá vỡ các bài kiểm tra đơn vị viết nhưng từ chối viết thêm (mà sẽ bao gồm những tính năng bổ sung của mã ông đã viết). Điều này dẫn đến một lỗ hổng lớn trong quy trình tdd (và thậm chí tệ hơn có thể là một hiệu ứng cửa sổ bị hỏng)

bất cứ điều gì tôi có thể làm để anh ta viết những bài kiểm tra đó? làm thế nào để bạn đối phó với những người đó?

Answer 1

Hãy nhớ rằng TDD không chủ yếu là tạo ra vùng phủ sóng thử nghiệm đơn vị tốt; đó là về động cơ thiết kế tốt trước tiên, về việc đảm bảo rằng mã bạn viết sẽ làm những gì bạn mong đợi thứ hai, và về việc cung cấp một cơ thể kiểm tra chất lượng cao thứ ba.

Khi một lập trình viên khác mở rộng một lớp học mà không cần viết bài kiểm tra, họ bỏ lỡ những lợi ích này và bạn sẽ cảm thấy thương hại với họ. Nhưng khi bạn làm việc, bạn sẽ tiếp tục làm việc theo cách tốt nhất mà bạn biết (kiểm tra trước) bởi vì bạn biết rằng bạn nhận được mã được tách riêng dễ dàng trên người tiêu dùng và mã của bạn làm những gì bạn mong đợi.

Nỗi đau lớn nhất với bạn là bạn phải cẩn thận về những gì bạn refactor: nếu bạn đang tái cấu trúc mã đang được kiểm tra, bạn có thể đi nhanh, và thiết kế sẽ nhanh chóng và an toàn cải thiện. Nếu bạn đang tái cấu trúc mã mà không được kiểm tra, bạn nên cực kỳ thận trọng về việc tái cấu trúc nó (có lẽ chỉ sử dụng các công cụ tự động đáng tin cậy để làm như vậy) hoặc thêm các thử nghiệm.

Cuối cùng, bạn sẽ tiếp tục được hưởng lợi từ việc sử dụng TDD, vì bạn tạo mã rõ ràng, chính xác hơn, nhanh hơn, trong khi đồng nghiệp bị TDD của bạn bị ảnh hưởng.

Answer 2

Ngoài chính sách của công ty và hậu quả từ người quản lý của họ, bạn không thể làm được gì nhiều. Có thể có một số cách trong công cụ Kiểm soát nguồn của bạn để yêu cầu bất kỳ công khai nào có thử nghiệm đơn vị được gắn cờ như vậy.

Bạn thậm chí có thể viết macro là một phần của quá trình xây dựng của bạn, tìm mọi thứ được đánh dấu PUBLIC (tôi là một người VB), và sau đó kiểm tra để đảm bảo rằng, ở đâu đó trong giải pháp, có một bài kiểm tra đơn vị với mã nhận xét rằng liên kết đầy đủ nó. Không có một bài kiểm tra đơn vị liên kết phá vỡ xây dựng và gửi một email cho toàn bộ nhóm dev mà đủ shames nói không thử nghiệm.

Có lẽ tôi sẽ thiết lập khả năng ở đây, bây giờ mà tôi nghĩ về nó ...

Answer 3

Nếu bạn có một quá trình xây dựng bạn có thể sử dụng một công cụ như NCover hoặc PartCover và không xây dựng chương trình bảo hiểm isn' t đủ.

Answer 4

Phạm vi mã theo dõi bằng một số công cụ, ví dụ: đối với Java có Emma và tạo báo cáo quản lý với mỗi bản phát hành. Khi số lượng quá thấp hoặc đi xuống quản lý nên điều tra nguyên nhân.

Answer 5

Lập trình ghép nối. Với hai người làm việc trên một cái gì đó, các lập trình viên ít có khả năng thực hiện các phím tắt như thế này.

Answer 6

Phát video của "Đừng theo dõi tôi!" guy as a warning

Answer 7

Đừng tiếp cận điều này như là một cuộc đối đầu!Bạn đang hỏi làm thế nào để buộc một đồng nghiệp làm một cái gì đó s/ông rõ ràng không thấy bất kỳ lợi ích. Bạn không thể khiến ai đó sử dụng TDD - như bạn đã thấy chính mình. Cách duy nhất một nhà phát triển sẽ nắm lấy TDD là khi ai đó giúp họ đạt được "aha!" chốc lát. Hãy tôn trọng như một đồng nghiệp khác và cho anh ta/cô ấy thông qua hành động của bạn và tích cực trong việc muốn giúp anh ta/cô ấy vượt qua bướu tinh thần.

Answer 8

Hãy dạy cho đồng nghiệp của bạn cách thực hiện TDD, để họ có thể lật ngược bộ não của mình (lần đầu tiên tôi thử TDD) và bắt đầu viết bài kiểm tra trước.

Khi tôi đã làm một thử nghiệm với một người bạn lập trình viên của tôi, người không biết TDD. Tôi đến nhà anh ấy và chúng tôi bắt đầu viết Tetris bằng TDD (chúng tôi đã dành khoảng 6 giờ ngày hôm đó và tiến bộ rất tốt). Đầu tiên tôi đã viết một phương pháp kiểm tra, và sau đó ông đã viết mã để vượt qua bài kiểm tra. Ban đầu anh ta hơi phản đối việc viết "điều đơn giản nhất có thể làm việc" (chẳng hạn như mã hóa cứng giá trị trả về trong các bài kiểm tra tầm thường đầu tiên) và không lên kế hoạch trước nhiều, nhưng dù sao anh ta đã hút nó và làm theo hướng dẫn của tôi. Khi chúng tôi tiến triển, có vẻ như từ từ anh ấy bắt đầu hiểu được điểm nào trong đó.

Answer 9

Dẫn đầu bằng ví dụ. Đồng nghiệp của bạn có thể không hiểu cách sử dụng TDD một cách thích hợp. Lần tới nó xảy ra, viết một bài kiểm tra đơn vị cho họ. Hãy chắc chắn để chỉ ra điều này cho họ: "Này, tôi nhận thấy bạn đã thêm x tính năng vào chương trình mà không có kiểm tra đơn vị, vì vậy tôi đã viết một cho bạn và đặt nó ở đây." Bằng cách này họ có một ví dụ và sẽ không cảm thấy xấu hổ bằng cách phải hỏi làm thế nào để kiểm tra đơn vị.

Chỉ thực hiện việc này một lần hoặc hai lần. Sau đó, hãy chắc chắn đề cập đến bất kỳ sự cố nào trong tương lai. Bạn sẽ ngạc nhiên trước sự khác biệt một cách lịch sự "Này, bạn đã không viết một bài kiểm tra đơn vị cho chức năng y, nó thực sự giúp tôi nếu bạn viết một cho tôi" sẽ thực hiện. Hãy nhớ rằng, mục tiêu của bạn không phải là cố gắng làm cho họ viết thử nghiệm. Đó là để làm cho các bài kiểm tra viết ít rắc rối hơn là không viết bài kiểm tra.

Nếu những điều trên không hiệu quả, đã đến lúc thảo luận với ban quản lý. Bạn đã cố gắng giải quyết tình huống một cách thân thiện, vì vậy đã đến lúc phải xem xét một cách tiếp cận ít thân thiện hơn.