Có thể âm thanh ngu ngốc, nhưng các bài kiểm tra đơn vị có hữu ích cho thực tế không?

Question

thể trùng lặp:
Is Unit Testing worth the effort?

Được rồi, tôi biết mục đích của kiểm tra đơn vị là những gì nói chung, nhưng tôi thấy một số điều mà làm phiền tôi.

1) Mục đích của kiểm tra phát hiện lỗi sớm. Vì vậy, trong một số lần lặp lại sau, nếu tôi thực hiện một số thay đổi trong mã, kiểm tra tự động phải báo động cho tôi và cho tôi biết rằng tôi đã làm hỏng một số phần mềm bị lãng quên trước đây của tôi.

Nhưng, nói rằng tôi có lớp A và nói đó là tương tác với một số lớp khác dụ, gọi nó là lớp B.

Khi ai viết unit test cho lớp A, ông đã chế nhạo lớp B. Vì vậy, trong một số tương lai, nếu có một số thay đổi trong lớp B, và gây ra một số lỗi, chúng sẽ chỉ phản ánh trong bài kiểm tra đơn vị lớp B chứ không phải trong A (vì bài kiểm tra A không sử dụng lớp B thực sự, nhưng nó là giả lập với đầu vào và đầu ra cố định). Vì vậy, tôi không thể thấy làm thế nào để kiểm tra đơn vị có thể sớm thông báo về các lỗi mà người ta không biết? Tôi biết các lỗi có thể xảy ra trong lớp mà tôi đang thay đổi, tôi không cần kiểm tra đơn vị cho nó, tôi cần kiểm tra để cảnh báo cho tôi về những hậu quả của những thay đổi của tôi. có thể với các bài kiểm tra đơn vị. Hoặc là tôi sai?

2) Khi viết mocks và sự mong đợi đúng của phương thức gọi, đầu vào và giá trị trả về, người ta phải biết cách thử nghiệm lớp học sẽ được triển khai như thế nào. Và tôi nghĩ rằng điều đó mâu thuẫn với sự phát triển thử nghiệm. Trong TDD người ta viết các bài kiểm tra đầu tiên, và, được thúc đẩy bởi họ, người ta viết một mã. Nhưng tôi không thể viết đúng mong đợi (và kiểm tra nói chung) trừ khi tôi viết mã phải được kiểm tra. Điều đó mâu thuẫn với TDD, phải không?

Cả hai vấn đề đó có thể được giải quyết nếu tôi sử dụng các đối tượng thực thay vì mocks. Nhưng đó không phải là thử nghiệm đơn vị sau đó, phải không? Trong bài kiểm tra đơn vị lớp dưới kiểm tra phải được cô lập hình thức phần còn lại của hệ thống, không sử dụng các lớp học thực tế nhưng mocks.

Tôi chắc chắn rằng mình sai ở đâu đó, nhưng tôi không thể tìm thấy ở đâu. Tôi đã đọc và đọc và tôi không thể tìm thấy những gì tôi đã hiểu sai.

Answer 1

Nói đúng ra, bạn dành nhiều thời gian hơn để viết bài kiểm tra đơn vị thay vì tập trung vào mã thực tế.

không có cách nào bạn có thể đạt được mức độ bao phủ 100% mã. Tôi làm đơn vị kiểm tra ứng dụng của tôi, nhưng tôi cảm thấy nó không đáng giá. Nhưng không phải ai cũng đồng ý với nó.

Nếu bạn thay đổi một đoạn mã, kiểm tra đơn vị của bạn không thành công và tìm ra lý do tại sao nó không thành công nhưng đối với tôi nó không đáng giá.

Tôi không fan hâm mộ lớn của Đơn vị kiểm tra ... Bạn thử tất cả mọi thứ nhưng mocking là nhiệm vụ lớn ..........

Nhưng bây giờ là một công ty ngày đang cố gắng để tiếp cận TDD.

Answer 2

Câu trả lời đơn giản: Có, chúng hữu ích cho thực.

TDD là tốt đẹp và tất cả trong lý thuyết nhưng tôi đã hầu như không bao giờ nhìn thấy nó được thực hiện trong thực tế. Unittests không bị ràng buộc để tdd, tuy nhiên.Bạn luôn có thể viết unittests cho mã hoạt động để đảm bảo mã vẫn hoạt động sau khi thay đổi. Việc sử dụng unittests này đã giúp tôi tiết kiệm vô số giờ sửa lỗi vì các bài kiểm tra ngay lập tức chỉ ra điều gì đã xảy ra.

Tôi có xu hướng tránh mocks. Trong hầu hết các trường hợp, chúng không đáng giá theo ý kiến ​​của tôi. Không sử dụng mocks có thể làm cho unittest của tôi nhiều hơn một chút của integrationtest nhưng nó được công việc làm. Để đảm bảo, các lớp học của bạn hoạt động như được thiết kế.

Answer 3

Tôi vừa mới triển khai TDD và thử nghiệm đơn vị lần đầu tiên. Tôi nghĩ rằng nó tuyệt vời, và tôi chưa bao giờ sử dụng nó trong một môi trường tích hợp tiếp giáp, nơi tôi tưởng tượng nó còn có giá trị hơn.

quá trình của tôi:

1. Tạo bộ xương của lớp học, nơi logic kinh doanh sẽ đi (có thể là một lớp serivce, hoặc đối tượng miền, vv).
2. Viết kiểm tra, và xác định các tên phương pháp và yêu cầu functionaility trong các thử nghiệm - mà sau đó sẽ nhắc ide của tôi để viết phương pháp Skelton (một cộng small but nice)
3. Sau đó viết các phương thức lớp thực tế đang được thử nghiệm.
4. Chạy kiểm tra, gỡ lỗi.

Tôi hiện không còn có thể viết mã mà không viết bài kiểm tra đầu tiên, nó thực sự hỗ trợ phát triển. Bạn bắt lỗi ngay lập tức, và nó thực sự giúp bạn tinh thần đặt hàng mã của bạn và phát triển một cách đơn giản có cấu trúc. Và tất nhiên, bất kỳ mã nào phá vỡ chức năng hiện tại đều bị bắt ngay lập tức.

Tôi chưa cần sử dụng các đối tượng giả lập (sử dụng mùa xuân tôi có thể thoát ngay với lớp dịch vụ gọi điện và phương thức điều khiển trực tiếp).

Answer 4

0) Không, không. Âm thanh ngu ngốc, ý tôi là. Đó là một câu hỏi hoàn toàn hợp lệ.

Thực tế đáng buồn là của chúng ta là một ngành công nghiệp thủng với những viên đạn bạc và trơn với dầu rắn, và nếu một cái gì đó không có ý nghĩa thì bạn có quyền đặt câu hỏi đó. Bất kỳ kỹ thuật nào, bất kỳ cách tiếp cận nào đối với bất kỳ bộ phận kỹ thuật nào cũng chỉ áp dụng trong một số trường hợp nhất định. Các tài liệu này thường được ghi nhận ở mức độ tốt nhất và do đó tất cả đều có xu hướng xấu đi thành các đối số hoàn toàn không có nghĩa là của tôi.

Tôi đã thành công và thất bại với thử nghiệm đơn vị, và theo kinh nghiệm của tôi, nó có thể rất hữu ích, khi được áp dụng đúng.

Nó không phải là một kỹ thuật tốt khi bạn đang làm một nỗ lực phát triển từ đầu, bởi vì mọi thứ đang thay đổi quá nhanh để các bài kiểm tra đơn vị theo kịp. Nó là một kỹ thuật tuyệt vời khi trong giai đoạn bảo trì, bởi vì bạn đang thay đổi một phần nhỏ của một toàn bộ lớn hơn mà vẫn cần phải làm việc theo cách nó được cho là.

Với tôi, kiểm tra đơn vị không phải là về phát triển theo hướng thử nghiệm mà là thiết kế theo hợp đồng: kiểm tra đơn vị kiểm tra xem giao diện có bị vi phạm hay không. Từ điều này, thật dễ dàng để thấy rằng cùng một người không nên viết một đơn vị và bài kiểm tra đơn vị tương ứng của nó, vì vậy đối với những thứ rất nhỏ, như dự án thú cưng của riêng tôi, tôi không bao giờ sử dụng nó. Trong các dự án lớn hơn, tôi ủng hộ nó - nhưng chỉ khi thiết kế theo hợp đồng được sử dụng và dự án nhận ra các đặc tả giao diện như các đồ tạo tác quan trọng.

Thử nghiệm đơn vị dưới dạng kỹ thuật cũng nhạy cảm với kích thước đơn vị. Nó không nhất thiết phải là trường hợp một lớp là có thể kiểm thử một mình, và theo kinh nghiệm của tôi, lớp học nói chung là quá nhỏ để thử nghiệm đơn vị.Bạn không muốn thử nghiệm một lớp học, bạn muốn thử nghiệm một đơn vị chức năng. Các tệp nhị phân có thể triển khai (có thể cài đặt) riêng lẻ, ví dụ: jars hoặc DLL, tạo các ứng cử viên tốt hơn trong sách của tôi hoặc các gói nếu bạn đang sử dụng ngôn ngữ kiểu Java.

Answer 5

Kiểm tra đơn vị không phải là ngu ngốc, nó phụ thuộc vào dự án của bạn.

Tôi nghĩ Bài kiểm tra đơn vị là tốt, không chỉ trong phát triển TDD mà còn ở bất kỳ loại dự án nào. Chuyên gia thực sự đối với tôi là nếu bạn bọc mã quan trọng trong dự án của mình với Bài kiểm tra đơn vị, có cách để biết liệu ý của bạn với nó vẫn đang hoạt động hay không.

Đối với tôi, vấn đề thực sự là nếu ai đó đang làm rối tung mã của bạn, sẽ có cách để anh ấy/cô ấy biết nếu các thử nghiệm vẫn chưa được giải quyết, nhưng không phải bằng cách chạy chúng theo cách thủ công. Ví dụ, cho phép lấy ví dụ Eclipse + Java + Maven. Nếu bạn sử dụng các bài kiểm tra Đơn vị trên Dự án Java Maven của bạn, mỗi khi có ai đó xây dựng nó, các thử nghiệm sẽ tự động chạy. Vì vậy, nếu ai đó làm rối tung mã của bạn, lần sau khi xây dựng nó, anh ta sẽ gặp lỗi "BUILD FAILED", chỉ ra rằng một số Kiểm tra Đơn vị không thành công. Vì vậy, quan điểm của tôi là: Kiểm tra đơn vị là tốt, nhưng mọi người nên biết rằng họ đang vặn vẹo mọi thứ mà không cần chạy thử nghiệm mỗi khi họ thay đổi mã.