Thử nghiệm đơn vị - không thể di chuyển từ lý thuyết sang thực hành

Question

Có vẻ như mọi ví dụ kiểm tra đơn vị mà tôi đã gặp đều cực kỳ rõ ràng và được đóng hộp. Những điều như khẳng định rằng x + 3 == 8, và whatnot. Tôi chỉ có một thời gian khó khăn nhìn thấy làm thế nào tôi sẽ đơn vị kiểm tra những thứ thế giới thực, như truy vấn SQL, hoặc nếu một regEx được sử dụng để xác nhận mẫu thực sự hoạt động đúng.

Trường hợp tại điểm: Tôi đang làm việc trên hai trang web ASP.NET MVC 2 được DB điều khiển. Tôi có một giải pháp đơn vị thử nghiệm cho mỗi người trong số họ, nhưng không có ý tưởng loại thử nghiệm sẽ hữu ích. Hầu hết công việc mà trang web sẽ làm là ghi dữ liệu vào hoặc truy xuất và tổ chức dữ liệu từ DB. Tôi chỉ đơn giản là sẽ thử nghiệm rằng các truy vấn khác nhau truy cập thành công DB? Làm cách nào để tôi kiểm tra tính chính xác (ví dụ: dữ liệu được ghi vào các trường thích hợp hoặc dữ liệu chính xác được truy lục)?

Tôi chỉ gặp khó khăn trong việc chuyển đổi cách thử nghiệm và gỡ lỗi không chính thức của mình thành loại thử nghiệm chính thức, khẳng định (x).

Answer 1

Đầu tiên, hãy tự hỏi "Tại sao các bài kiểm tra đơn vị khó viết cho mã thực của tôi?" Có lẽ câu trả lời là mã thực sự của bạn đang làm quá nhiều. Nếu bạn có một mô-đun mã đầy các câu lệnh "mới" và câu lệnh "nếu" và "chuyển đổi" và câu lệnh toán học thông minh và truy cập cơ sở dữ liệu thì sẽ rất khó để viết một bài kiểm tra, hãy để một mình kiểm tra đầy đủ logic và môn Toán. Nhưng nếu bạn kéo các câu lệnh "mới" vào một phương thức của nhà máy, bạn có thể dễ dàng cung cấp các đối tượng giả để kiểm tra.Nếu bạn kéo các mệnh đề "if" và các câu lệnh "chuyển đổi" ra thành các mẫu máy trạng thái, bạn sẽ không có quá nhiều kết hợp để kiểm tra. Nếu bạn loại bỏ quyền truy cập cơ sở dữ liệu vào một đối tượng nhà cung cấp dữ liệu ngoài, bạn có thể cung cấp dữ liệu thử nghiệm đơn giản để thực thi các câu lệnh toán học của mình. Bây giờ bạn đang thử nghiệm việc tạo đối tượng, chuyển tiếp trạng thái và truy cập dữ liệu một cách riêng biệt từ các câu lệnh toán học thông minh của bạn. Tất cả các bước này trở nên dễ dàng hơn bằng cách đơn giản hóa chúng.

Mã lý do chính khó kiểm tra là mã chứa "phụ thuộc nội bộ", chẳng hạn như phụ thuộc mà nó tạo hoặc phụ thuộc vào thư viện. Nếu mã của bạn nói "Foo theFoo = new Foo();" bạn không thể dễ dàng thay thế một MockFoo để thử nghiệm. Nhưng nếu phương thức khởi tạo hoặc phương thức của bạn yêu cầu theFoo được truyền vào thay vì xây dựng chính nó, thì việc khai thác thử nghiệm của bạn có thể dễ dàng vượt qua trong một MockFoo.

Khi bạn viết mã, hãy tự hỏi "làm cách nào tôi có thể viết một bài kiểm tra đơn vị cho mã này?" Nếu câu trả lời là "khó", bạn có thể xem xét thay đổi mã của mình để dễ kiểm tra hơn. Điều này làm cho đơn vị của bạn kiểm tra người tiêu dùng thực tế đầu tiên của mã của bạn - bạn đang thử nghiệm giao diện cho mã của mình bằng cách viết thử nghiệm.

Bằng cách thay đổi giao diện của bạn để dễ kiểm tra hơn, bạn sẽ thấy mình tôn trọng tốt hơn các nguyên tắc hướng đối tượng "gắn kết chặt chẽ" và "khớp nối lỏng lẻo".

Kiểm tra đơn vị không chỉ là về các thử nghiệm. Viết bài kiểm tra đơn vị thực sự cải thiện thiết kế của bạn. Đi xa hơn một chút trên con đường, và bạn kết thúc với Test Driven Development.

Chúc may mắn!

Answer 2

Để thử nghiệm đơn vị khả thi, mã của bạn sẽ phải áp dụng cho các nguyên tắc gắn kết và tách. Trong thực tế, nó sẽ buộc các nguyên tắc đó trên mã của bạn khi bạn áp dụng nó. Có nghĩa là, nếu mã của bạn không được xác định rõ ràng (tức là nguyên tắc thiết kế OO được áp dụng chính xác), kiểm tra đơn vị sẽ không thể thực hiện được và/hoặc vô ích. Vì vậy, có lẽ, cách tốt hơn để bạn suy nghĩ về điều này sẽ là 'Làm cách nào tôi có thể chia tất cả công việc của ứng dụng thành các đoạn mã nhỏ hơn, gắn kết hơn mà chỉ làm một hoặc hai thứ và sử dụng chúng để lắp ráp ứng dụng của tôi?'

Cho đến khi bạn đã nội tâm hóa suy nghĩ này về cách bạn suy nghĩ về mã của mình, kiểm thử đơn vị có thể sẽ không có ý nghĩa.

Answer 3

Vâng, nếu x + 3 == 8 không đủ gợi ý, thì khoảng x==y?

Nói cách khác, những gì bạn đang thử nghiệm là hành vi chính xác và không chính xác của các loại hoặc chức năng, không chỉ khi được sử dụng với điều kiện thông thường, mà còn trong các điều kiện bất ngờ. Với một lớp học, ví dụ bạn cần phải nhận ra rằng chỉ cần instantiating là không đủ. Các điều kiện tiên quyết của lớp có được đáp ứng không? Điều gì về các điều kiện sau? Điều gì sẽ xảy ra khi chúng không được đáp ứng? Đây là nơi bạn thiết lập các ranh giới giữa bạn và người sử dụng lớp (cũng có thể là bạn, tất nhiên) để phân biệt giữa một lỗi trong lớp hoặc một lỗi trong việc sử dụng lớp bởi người dùng. Làm trường hợp của trạng thái thay đổi lớp học của bạn khi được sử dụng với các mẫu mã hóa cụ thể? Nếu vậy, làm thế nào? Nếu không, tại sao không, và (lý tưởng) trong tất cả các điều kiện sử dụng có thể; hành vi này có đúng không?
Bài kiểm tra đơn vị cũng là nơi tốt cho người dùng của lớp (ví dụ) để xem lớp học được sử dụng như thế nào, cách tránh sử dụng và điều gì có thể xảy ra trong trường hợp ngoại lệ (nếu xảy ra sự cố, lớp của bạn được cho là sẽ phản ứng theo một cách nào đó thay vì chỉ đơn giản là phá vỡ). Sắp xếp giống như tài liệu được tích hợp sẵn cho nhà phát triển.

Answer 4

Có lẽ việc học từ ví dụ sẽ hữu ích nhất cho bạn. Bạn có thể xem qua số NerdDinner sample app và xem loại thử nghiệm nào. Bạn cũng có thể xem bản thân số MVC source code và xem nó được kiểm tra như thế nào.