Điều tôi nhận thấy về TDD là cần có thời gian để thiết lập các bài kiểm tra của bạn và bản chất là tôi lười biếng, tôi luôn muốn viết càng ít mã càng tốt. Điều đầu tiên tôi có vẻ làm là kiểm tra hàm tạo của tôi đã đặt tất cả các thuộc tính nhưng điều này có quá mức cần thiết không?
Câu hỏi của tôi là bạn viết các bài kiểm tra đơn vị ở mức độ chi tiết nào?
..và có trường hợp thử nghiệm quá nhiều không?
Câu trả lời:
Tôi được trả tiền cho mã hoạt động, không phải cho các bài kiểm tra, vì vậy triết lý của tôi là kiểm tra càng ít càng tốt để đạt được mức độ tin cậy nhất định (tôi nghi ngờ mức độ tự tin này cao so với tiêu chuẩn ngành, nhưng đó có thể chỉ là sự hách dịch) . Nếu tôi thường không mắc một loại lỗi nào (như đặt sai biến trong một hàm tạo), tôi sẽ không kiểm tra nó. Tôi có xu hướng hiểu rõ các lỗi kiểm tra, vì vậy tôi đặc biệt cẩn thận khi tôi logic với các điều kiện phức tạp. Khi viết mã cho một nhóm, tôi sửa đổi chiến lược của mình để kiểm tra cẩn thận mã mà chúng tôi, nói chung, có xu hướng sai.
Những người khác nhau sẽ có các chiến lược thử nghiệm khác nhau dựa trên triết lý này, nhưng điều đó có vẻ hợp lý đối với tôi khi chưa hiểu rõ về cách các thử nghiệm có thể phù hợp nhất với vòng lặp bên trong của mã hóa. Mười hoặc hai mươi năm nữa, chúng ta có thể sẽ có một lý thuyết phổ quát hơn về bài kiểm tra nào nên viết, bài kiểm tra nào không viết và cách phân biệt sự khác biệt. Trong khi đó, thử nghiệm có vẻ theo thứ tự.
Viết các bài kiểm tra đơn vị cho những thứ bạn mong đợi sẽ phá vỡ và cho các trường hợp cạnh. Sau đó, các trường hợp thử nghiệm sẽ được thêm vào khi có báo cáo lỗi - trước khi viết bản sửa lỗi. Sau đó, nhà phát triển có thể tự tin rằng:
Theo nhận xét đính kèm - tôi đoán cách tiếp cận này để viết các bài kiểm tra đơn vị có thể gây ra vấn đề, nếu nhiều lỗi được phát hiện theo thời gian trong một lớp nhất định. Đây có lẽ là nơi tùy ý sẽ hữu ích - chỉ thêm các bài kiểm tra đơn vị cho các lỗi có khả năng tái xuất hiện hoặc trường hợp chúng tái xuất hiện sẽ gây ra các vấn đề nghiêm trọng. Tôi nhận thấy rằng một biện pháp kiểm tra tích hợp trong các bài kiểm tra đơn vị có thể hữu ích trong những trường hợp này - mã kiểm tra mã cao hơn các đường dẫn có thể bao phủ các đường dẫn thấp hơn.
Mọi thứ nên được làm đơn giản nhất có thể, nhưng không đơn giản hơn. - A. Einstein
Một trong những điều bị hiểu lầm nhiều nhất về TDD là từ đầu tiên trong đó. Kiểm tra. Đó là lý do tại sao BDD xuất hiện. Bởi vì mọi người không thực sự hiểu rằng chữ D đầu tiên là quan trọng, cụ thể là Driven. Tất cả chúng ta đều có xu hướng nghĩ một chút về Thử nghiệm và một chút về động lực của thiết kế. Và tôi đoán rằng đây là một câu trả lời mơ hồ cho câu hỏi của bạn, nhưng có lẽ bạn nên xem xét cách điều khiển mã của mình, thay vì những gì bạn thực sự đang thử nghiệm; đó là điều mà một công cụ Bảo hiểm có thể giúp bạn. Thiết kế là một vấn đề khá lớn và nhiều vấn đề hơn.
Đối với những người đề xuất thử nghiệm "mọi thứ": hãy nhận ra rằng "thử nghiệm hoàn toàn" một phương pháp như int square(int x)yêu cầu khoảng 4 tỷ trường hợp thử nghiệm trong các ngôn ngữ phổ biến và môi trường điển hình.
Trong thực tế, nó thậm chí còn tồi tệ hơn rằng: một phương pháp void setX(int newX)cũng có nghĩa vụ không làm thay đổi các giá trị của bất kỳ thành viên nào khác ngoài x- bạn đang thử nghiệm mà obj.y, obj.zvv tất cả vẫn không thay đổi sau khi gọi obj.setX(42);?
Chỉ thực tế khi kiểm tra một tập hợp con của "mọi thứ". Một khi bạn chấp nhận điều này, bạn sẽ thấy dễ chịu hơn khi xem xét việc không thử nghiệm các hành vi cực kỳ cơ bản. Mọi lập trình viên đều có phân bố xác suất của các vị trí lỗi; cách tiếp cận thông minh là tập trung sức lực của bạn vào các khu vực thử nghiệm mà bạn ước tính xác suất lỗi là cao.
Câu trả lời cổ điển là "kiểm tra bất cứ thứ gì có thể phá vỡ". Tôi giải thích điều đó có nghĩa là bộ cài đặt và bộ nhận thử nghiệm không làm bất cứ điều gì ngoại trừ bộ hoặc nhận có thể là quá nhiều thử nghiệm, không cần phải mất thời gian. Trừ khi IDE của bạn viết những thứ đó cho bạn, thì bạn cũng có thể.
Nếu phương thức khởi tạo của bạn không thiết lập các thuộc tính có thể dẫn đến lỗi sau này, thì việc kiểm tra xem chúng được đặt không là quá mức cần thiết.
Tôi viết các bài kiểm tra để bao hàm các giả định của các lớp tôi sẽ viết. Các bài kiểm tra thực thi các yêu cầu. Về cơ bản, nếu x không bao giờ có thể là 3, chẳng hạn, tôi sẽ đảm bảo có một bài kiểm tra đáp ứng yêu cầu đó.
Luôn luôn, nếu tôi không viết một bài kiểm tra để bao gồm một điều kiện, nó sẽ xuất hiện sau đó trong quá trình kiểm tra "con người". Sau đó chắc chắn tôi sẽ viết một cuốn, nhưng tôi muốn nắm bắt chúng sớm hơn. Tôi nghĩ vấn đề là việc kiểm tra là tẻ nhạt (có lẽ) nhưng cần thiết. Tôi viết đủ các bài kiểm tra để hoàn thành nhưng không nhiều hơn thế.
Một phần của vấn đề với việc bỏ qua các bài kiểm tra đơn giản bây giờ là trong tương lai việc tái cấu trúc có thể làm cho thuộc tính đơn giản đó trở nên rất phức tạp với nhiều logic. Tôi nghĩ ý tưởng tốt nhất là bạn có thể sử dụng Kiểm tra để xác minh các yêu cầu đối với mô-đun. Nếu khi bạn vượt qua điểm X, bạn sẽ nhận lại được Y, thì đó là điều bạn muốn kiểm tra. Sau đó, khi bạn thay đổi mã sau này, bạn có thể xác minh rằng X mang lại cho bạn Y và bạn có thể thêm một bài kiểm tra cho A cho bạn B, khi yêu cầu đó được thêm vào sau này.
Tôi nhận thấy rằng thời gian tôi dành cho các bài kiểm tra viết phát triển ban đầu được đền đáp trong lần sửa lỗi đầu tiên hoặc thứ hai. Khả năng nhận mã mà bạn chưa xem xét trong 3 tháng và đảm bảo hợp lý rằng bản sửa lỗi của bạn bao gồm tất cả các trường hợp và "có thể" không phá vỡ bất cứ điều gì là cực kỳ có giá trị. Bạn cũng sẽ thấy rằng các bài kiểm tra đơn vị sẽ giúp phân loại lỗi vượt ra ngoài dấu vết ngăn xếp, v.v. Xem cách các phần riêng lẻ của ứng dụng hoạt động và không thành công sẽ cung cấp cái nhìn sâu sắc về lý do tại sao chúng hoạt động hay thất bại nói chung.
Trong hầu hết các trường hợp, tôi muốn nói, nếu có logic ở đó, hãy kiểm tra nó. Điều này bao gồm các hàm tạo và thuộc tính, đặc biệt khi có nhiều thứ được đặt trong thuộc tính.
Đối với việc thử nghiệm quá nhiều, điều đó còn gây tranh cãi. Một số người nói rằng mọi thứ nên được kiểm tra về độ chắc chắn, những người khác nói rằng để kiểm tra hiệu quả, chỉ những thứ có thể bị hỏng (tức là logic) mới nên được kiểm tra.
Tôi sẽ nghiêng nhiều hơn về trại thứ hai, chỉ từ kinh nghiệm cá nhân, nhưng nếu ai đó quyết định thử nghiệm mọi thứ, tôi sẽ không nói rằng nó quá nhiều ... một chút quá mức cần thiết có thể đối với tôi, nhưng không quá nhiều đối với họ.
Vì vậy, Không - tôi sẽ nói rằng không có cái gọi là thử nghiệm "quá nhiều" theo nghĩa chung, chỉ dành cho cá nhân.
Phát triển theo hướng kiểm tra nghĩa là bạn ngừng viết mã khi tất cả các thử nghiệm của bạn vượt qua.
Nếu bạn không có thử nghiệm cho một thuộc tính, thì tại sao bạn nên triển khai nó? Nếu bạn không kiểm tra / xác định hành vi mong đợi trong trường hợp được chuyển nhượng "bất hợp pháp", tài sản phải làm gì?
Vì vậy, tôi hoàn toàn để kiểm tra mọi hành vi mà một lớp nên thể hiện. Bao gồm các thuộc tính "nguyên thủy".
Để làm cho việc kiểm tra này dễ dàng hơn, tôi đã tạo một NUnit đơn giản TestFixturecung cấp các điểm mở rộng để thiết lập / nhận giá trị và lấy danh sách các giá trị hợp lệ và không hợp lệ, đồng thời có một bài kiểm tra duy nhất để kiểm tra xem thuộc tính có hoạt động đúng hay không. Kiểm tra một thuộc tính có thể trông giống như sau:
[TestFixture]
public class Test_MyObject_SomeProperty : PropertyTest<int>
{
private MyObject obj = null;
public override void SetUp() { obj = new MyObject(); }
public override void TearDown() { obj = null; }
public override int Get() { return obj.SomeProperty; }
public override Set(int value) { obj.SomeProperty = value; }
public override IEnumerable<int> SomeValidValues() { return new List() { 1,3,5,7 }; }
public override IEnumerable<int> SomeInvalidValues() { return new List() { 2,4,6 }; }
}
Sử dụng lambdas và các thuộc tính, điều này thậm chí có thể được viết gọn gàng hơn. Tôi thu thập MBUnit thậm chí có một số hỗ trợ bản địa cho những thứ như vậy. Tuy nhiên, vấn đề là đoạn mã trên nắm bắt được mục đích của thuộc tính.
Tái bút: Có lẽ PropertyTest cũng nên có một cách để kiểm tra xem các thuộc tính khác trên đối tượng không thay đổi. Hmm .. quay lại bảng vẽ.
Tôi thực hiện thử nghiệm đơn vị để đạt được phạm vi khả thi tối đa. Nếu tôi không thể đạt được một số mã, tôi sẽ cấu trúc lại cho đến khi phạm vi bảo hiểm đầy đủ nhất có thể
Sau khi hoàn thành bài kiểm tra viết chói mắt, tôi thường viết một trường hợp kiểm tra sao chép từng lỗi
Tôi đã từng phân biệt giữa kiểm tra mã và kiểm tra tích hợp. Trong quá trình kiểm tra tích hợp, (cũng là kiểm thử đơn vị nhưng trên các nhóm thành phần, vì vậy không chính xác kiểm thử đơn vị dùng để làm gì), tôi sẽ kiểm tra các yêu cầu để được triển khai chính xác.
Vì vậy, tôi càng thúc đẩy lập trình của mình bằng cách viết các bài kiểm tra, tôi càng ít lo lắng về mức độ chi tiết của bài kiểm tra. Nhìn lại, có vẻ như tôi đang làm điều đơn giản nhất có thể để đạt được mục tiêu xác thực hành vi . Điều này có nghĩa là tôi đang tạo ra một lớp tự tin rằng mã của tôi đang làm những gì tôi yêu cầu, tuy nhiên điều này không được coi là đảm bảo tuyệt đối rằng mã của tôi không có lỗi. Tôi cảm thấy rằng sự cân bằng chính xác là để kiểm tra hành vi tiêu chuẩn và có thể là một hoặc hai trường hợp cạnh sau đó chuyển sang phần tiếp theo của thiết kế của tôi.
Tôi chấp nhận rằng điều này sẽ không bao gồm tất cả các lỗi và sử dụng các phương pháp kiểm tra truyền thống khác để nắm bắt chúng.
Nói chung, tôi bắt đầu với quy mô nhỏ, với các đầu vào và đầu ra mà tôi biết phải hoạt động. Sau đó, khi tôi sửa lỗi, tôi thêm nhiều bài kiểm tra hơn để đảm bảo những thứ tôi đã sửa được kiểm tra. Nó hữu cơ và hoạt động tốt cho tôi.
Bạn có thể kiểm tra quá nhiều? Có thể, nhưng có lẽ tốt hơn hết là bạn nên thận trọng nói chung, mặc dù nó sẽ phụ thuộc vào mức độ quan trọng của ứng dụng của bạn.
Tôi nghĩ bạn phải kiểm tra mọi thứ trong "cốt lõi" của logic kinh doanh của bạn. Getter ans Setter cũng vậy vì họ có thể chấp nhận giá trị âm hoặc giá trị null mà bạn có thể không muốn chấp nhận. Nếu bạn có thời gian (luôn phụ thuộc vào sếp của bạn), tốt hơn là bạn nên kiểm tra logic nghiệp vụ khác và tất cả bộ điều khiển gọi đối tượng này (bạn đi từ kiểm tra đơn vị đến kiểm tra tích hợp một cách chậm rãi).
Tôi không kiểm tra đơn vị các phương pháp setter / getter đơn giản mà không có tác dụng phụ. Nhưng tôi kiểm tra đơn vị mọi phương pháp công khai khác. Tôi cố gắng tạo các bài kiểm tra cho tất cả các điều kiện biên trong biệt danh của mình và kiểm tra mức độ phù hợp của các bài kiểm tra đơn vị của tôi.
Nó rất nhiều công việc nhưng tôi nghĩ nó xứng đáng. Tôi muốn viết mã (thậm chí mã thử nghiệm) hơn là từng bước qua mã trong trình gỡ lỗi. Tôi thấy chu kỳ mã-xây dựng-triển khai-gỡ lỗi rất tốn thời gian và các bài kiểm tra đơn vị tôi đã tích hợp vào bản dựng của mình càng đầy đủ thì tôi càng dành ít thời gian hơn cho chu trình mã-xây dựng-triển khai-gỡ lỗi đó.
Bạn không nói lý do tại sao kiến trúc mà bạn đang viết mã. Nhưng đối với Java, tôi sử dụng Maven 2 , JUnit , DbUnit , Cobertura và EasyMock .
Càng đọc về nó, tôi càng nghĩ rằng một số bài kiểm tra đơn vị chỉ giống như một số mẫu: Một mùi không đủ ngôn ngữ.
Khi bạn cần kiểm tra xem liệu getter tầm thường của bạn có thực sự trả về giá trị phù hợp hay không, đó là vì bạn có thể trộn lẫn tên getter và tên biến thành viên. Nhập 'attr_reader: name' của ruby và điều này không thể xảy ra nữa. Chỉ là không thể trong java.
Nếu getter của bạn trở nên không đáng kể, bạn vẫn có thể thêm một bài kiểm tra cho nó sau đó.
Kiểm tra mã nguồn khiến bạn lo lắng về nó.
Không hữu ích khi kiểm tra các phần mã mà bạn rất tin tưởng, miễn là bạn không mắc lỗi trong đó.
Kiểm tra các bản sửa lỗi để đây là lần đầu tiên và lần cuối cùng bạn sửa lỗi.
Kiểm tra để có được sự tự tin về các phần mã khó hiểu, để bạn tạo ra kiến thức.
Kiểm tra trước khi tái cấu trúc mức độ nặng và trung bình để bạn không phá vỡ các tính năng hiện có.
Câu trả lời này nhiều hơn để tìm ra có bao nhiêu bài kiểm tra đơn vị để sử dụng cho một phương pháp nhất định mà bạn biết rằng bạn muốn kiểm tra đơn vị do mức độ nghiêm trọng / tầm quan trọng của nó. Sử dụng kỹ thuật Kiểm tra đường dẫn cơ sở của McCabe, bạn có thể thực hiện những điều sau để về mặt định lượng có độ tin cậy về độ bao phủ mã tốt hơn so với "phạm vi câu lệnh" hoặc "phạm vi nhánh" đơn giản: