2012-01-28 30 views
5

Tôi đã viết một lớp dòng 220 với 5 phương pháp công cộng. Tôi có một lớp thử nghiệm đơn vị chạy 28 bài kiểm tra trên lớp này, chiếm hơn 1200 dòng mã, nhưng điều này chủ yếu là do mã lặp lại được sử dụng trong việc thiết lập các bài kiểm tra. Mã này đang thử nghiệm DAL trong dự án của tôi để đảm bảo nó tương tác với cơ sở dữ liệu một cách chính xác và các thủ tục được lưu trữ có liên quan đang chạy đúng. Có vẻ như tôi đã làm rất nhiều công việc để kiểm tra rất ít mã. Tôi đang sử dụng mocks với tê giác tê giác để tránh viết bài của riêng tôi nếu có thể.Đây có phải là trải nghiệm thử nghiệm đơn vị điển hình không?

Đây có phải là trải nghiệm kiểm tra đơn vị điển hình không?

+1

tại sao bạn cho rằng trùng lặp là ok trong các thử nghiệm? – flq

+4

+1 để bù đắp mức giảm. Stack Overflow được thiết kế để giúp cả lập trình viên mới và có kinh nghiệm, và tôi nghĩ rằng hầu hết chúng ta có câu hỏi này ở một thời điểm nào đó. –

+0

Sự trùng lặp có thể là một tác dụng phụ của việc cố gắng giữ cho các bài kiểm tra không có trạng thái, một cái gì đó đòi hỏi nhiều nỗ lực hơn khi giao dịch với một cơ sở dữ liệu. Mặc dù vậy, tốt nhất là theo dõi DRY càng gần càng tốt. – ose

Trả lời

2

Đó là khá phổ biến rằng các lớp thử nghiệm đơn vị chứa LOC nhiều hơn các lớp được kiểm tra thực tế. Đó là hợp lý xem xét thiết lập phụ thuộc, chuẩn bị dữ liệu giả mạo và tất cả các đơn vị kiểm tra liên quan đến fuss.

Tuy nhiên, hãy thử nghiệm DAL về tương tác với cơ sở dữ liệu và kiểm tra xem các thủ tục chính xác có được gọi là mùi như thử nghiệm tích hợp hay không. Bạn có thể muốn suy nghĩ lại những gì bạn muốn làm. Với thử nghiệm đơn vị, tất cả các DB-nói chuyện nên được chế giễu/stubbed.

Nếu bạn gặp sự cố với 1200 dòng mã, bạn có thể chia nhỏ các thử nghiệm của mình thành ngữ cảnh, ví dụ: mọi ngữ cảnh phù hợp với một phần cụ thể của lớp được kiểm tra (phương thức công khai, tập hợp các thuộc tính và vv).

Edit:

Chỉ cần thêm ví dụ khác làm là tốt đó. Bạn có thể kiểm tra nguồn của các lớp AggregateAggregateTests từ dự án Edulinq.15 bài kiểm tra để kiểm tra 3 phương pháp công cộng, với các bài kiểm tra lớp được hai lần lớn như thử nghiệm một.

2

Có điều này là khá bình thường đối với thử nghiệm đơn vị.

Kích thước của mã cần thiết để chạy thử nghiệm thường được đánh giá thấp, đặc biệt là mã yêu cầu rất nhiều thiết lập boilerplate, chẳng hạn như truy cập cơ sở dữ liệu.

Trong khi bạn có thể cố gắng cấu trúc lại mã thiết lập thành các phương pháp riêng biệt, điều này là khá bình thường đối với trường hợp bạn mô tả.

Với 28 thử nghiệm, 1200 dòng của bạn giảm xuống còn khoảng 43 cho mỗi thử nghiệm. Xem xét bạn đang lặp lại mã thiết lập của bạn điều này là khá hợp lý.

+0

Như flq đã nhận xét, bạn nên chuyển mã chung thành một phương thức riêng biệt. Nó làm giảm cơ hội của các lỗi sao chép và dán, cho phép bạn viết các bài kiểm tra mới nhanh hơn và ngăn cản bản mẫu không che khuất mục đích chính của mỗi bài kiểm tra. –

+0

Một điều nữa: các dòng mã được coi là một thước đo khá kém về "kích cỡ". Câu hỏi này có lẽ không xứng đáng với thời gian và công sức để sử dụng các số liệu phức tạp hơn, nhưng tất cả đều không băn khoăn quá nhiều so với LOC. – ose

1

28 bài kiểm tra cho một lớp có vẻ giống như lớp đang làm quá nhiều thứ.

+0

Trong khi tôi đồng ý, có những tình huống mà nhiều bài kiểm tra có thể được yêu cầu. Mặc dù điều đó có thể được giảm bằng cách sử dụng tính năng 'Test Case' mới trên nunit –

+7

Tôi không đồng ý. Các bài kiểm tra đơn vị rất nhỏ; mỗi xác minh một khía cạnh cụ thể và có thể không bao gồm toàn bộ phương pháp. Ví dụ, nếu tôi đang thử nghiệm phương thức "setUserName", tôi sẽ có các kiểm tra riêng biệt cho đầu vào rỗng, đầu vào trống, đầu vào quá dài, đầu vào với các ký tự không hợp lệ và đầu vào hợp lệ ... chính xác những gì đã đi sai nếu một trong những faled. Đó là 5 bài kiểm tra cho một phương pháp, chỉ dành cho người mới bắt đầu! –

3

Theo cách nào điển hình?

Nếu bạn có nghĩa là bạn có nhiều mã kiểm tra đơn vị hơn mã thực, thì có. Nhưng bạn nên xử lý mã kiểm tra đơn vị của bạn theo cách tương tự như mã 'thực' của bạn trong đó bạn nên loại bỏ trùng lặp và tái cấu trúc nó cho đến khi nó càng gọn gàng càng tốt/mong muốn.

Ngoài ra, nếu bạn đang kiểm tra DAL và tương tác với cơ sở dữ liệu thực thì những gì bạn có ở đó là kiểm tra tích hợp.

EDIT

Tôi vừa mới đưa đến viết đơn vị lớp cơ sở kiểm tra các mẫu thử nghiệm thông thường, tôi có rất nhiều mã cài đặt và phương pháp helper trong đó. Lớp cơ sở thử nghiệm đơn vị gần đây nhất của tôi là lớp chung cho phép tôi kiểm tra các lớp wcf-web-api rất dễ dàng. Vì vậy, các lớp kiểm tra thực tế của tôi rất gầy và 'đến mức'. YMMV

+0

Cũng chỉ ra kiểm tra tích hợp lại. – ose

1

Bạn có thể muốn thử viết một số thử nghiệm chạy trực tiếp với cơ sở dữ liệu và xem xét điều đó có tốt hơn không. Tôi tìm thấy nhiều công việc hơn để có được các thiết lập cơ sở dữ liệu, nhưng sau đó ít làm việc như tôi không cần phải giả mạo các lớp thấp hơn. Các bài kiểm tra chạy chậm hơn, nhưng họ kiểm tra mọi thứ hoàn toàn hơn. Tất nhiên, nó không thực sự là một thử nghiệm đơn vị vào thời điểm này.

Các vấn đề liên quan