2013-05-23 64 views
24

Tôi bắt đầu sử dụng thử nghiệm đơn vị trong các dự án của mình và đang viết các thử nghiệm đang thử nghiệm ở cấp phương thức/chức năng.Chính xác thử nghiệm tích hợp là gì - so với đơn vị

Tôi hiểu điều này và điều đó có ý nghĩa.

Nhưng thử nghiệm tích hợp là gì? Từ những gì tôi đọc nó di chuyển phạm vi của thử nghiệm lên để kiểm tra các tính năng lớn hơn của một ứng dụng.

này ngụ ý rằng tôi viết một bộ kiểm tra mới để thử nghiệm những thứ lớn hơn như (trên một trang web thương mại điện tử) chức năng kiểm tra, chức năng đăng nhập của người dùng, chức năng giỏ. Vì vậy, ở đây tôi sẽ có 3 bài kiểm tra tích hợp được viết?

Điều này có đúng không - nếu không ai đó có thể giải thích ý nghĩa của nó.

Ngoài ra, kiểm tra tích hợp có liên quan đến ui (ngữ cảnh ứng dụng web ở đây) và sẽ sử dụng số selen để tự động hóa. Hoặc là thử nghiệm tích hợp vẫn ở cấp mã nhưng buộc các lớp khác nhau và các khu vực của mã.

Trả lời

25

Hãy xem xét một phương pháp như thế này PerformPayment(double amount, PaymentService service);

Một đơn vị kiểm tra sẽ là một thử thách mà bạn tạo ra một mô hình cho các đối số service.

Kiểm tra tích hợp sẽ là thử nghiệm nơi bạn sử dụng dịch vụ bên ngoài thực tế để bạn kiểm tra xem dịch vụ đó có phản hồi chính xác với dữ liệu đầu vào của bạn hay không.

+0

Vì vậy, chúng được thực hiện ở cấp độ ui? sử dụng selenium nói, hoặc là có một bộ thử nghiệm bằng văn bản, tương tự như bộ thử nghiệm đơn vị nhưng chỉ rộng hơn trong phạm vi? –

+0

Không nhất thiết. Hãy nghĩ về PaymentService bằng tài nguyên bên ngoài, chẳng hạn như cơ sở dữ liệu hoặc API của bên thứ ba. Có thể mất vài giây để truy cập (vào một ngày tồi tệ) hoặc nó có thể chỉ là một quy trình chạy dài. Nó quá chậm để kiểm tra đơn vị (do đó chế nhạo nó ra), nhưng bạn vẫn muốn thử nghiệm nó để đảm bảo nó hoạt động đúng. Đó là nơi thử nghiệm tích hợp đi vào. Họ không phải là kiểm tra bạn chạy nhiều lần, thường là trước khi thực hiện một bản phát hành hoặc bạn có CI của bạn chạy chúng. – firelore

0

Theo như tôi thấy các thử nghiệm selen phải ở trong một bộ thử nghiệm khác. Những thử nghiệm đó là thử nghiệm dễ vỡ nhất trong tự nhiên ngay cả khi bạn viết chúng một cách chính xác. Ở đây bạn có thể sử dụng Specflow hoặc một số loại đặc tả khác bằng khung ví dụ. Có lẽ bạn có thể gọi những bài kiểm tra này là bài kiểm tra chấp nhận. Đây cũng là cho các nhà phát triển và các chuyên gia kinh doanh. Kiểm tra tích hợp hoặc mô-đun thường không sử dụng giao diện người dùng. Các bài kiểm tra tích hợp thực hiện một số lớp đang làm việc cùng nhau. Đây là các bài kiểm tra cấp thấp hơn so với các bài kiểm tra selen, và dễ bảo trì hơn một chút. Những thử nghiệm này chỉ dành cho nhà phát triển.

0

Dưới đây là một số hạn chế mà thử nghiệm đơn vị tốt đáp ứng. Đáp ứng các ràng buộc này cũng yêu cầu mã có thể thử nghiệm tốt.

  1. Không I/O - đĩa hoặc mạng
  2. Chỉ có một sự khẳng định (nếu nhiều, họ sẽ có sự thay đổi nhỏ của nhau)
  3. Không tập thể dục (cover) mã sản xuất nhiều hơn so với những gì nó khẳng định

Những ràng buộc này thường không áp dụng cho các thử nghiệm tích hợp.

1

Thử nghiệm đơn vị là nơi bạn đang thử nghiệm logic kinh doanh của mình trong một lớp học hoặc một đoạn mã. Ví dụ, nếu bạn đang kiểm tra một phần cụ thể của phương thức của bạn nên gọi một kho lưu trữ, kiểm tra đơn vị của bạn sẽ kiểm tra để đảm bảo rằng phương thức của giao diện gọi là kho được gọi là số lần chính xác mà bạn mong đợi. các bài kiểm tra.

Kiểm tra tích hợp mặt khác là thử nghiệm rằng hành vi dịch vụ thực tế hoặc kho lưu trữ (cơ sở dữ liệu) là chính xác. Nó đang kiểm tra dựa trên dữ liệu bạn truyền vào, bạn lấy kết quả mong đợi. Điều này liên kết với các bài kiểm tra đơn vị của bạn để bạn biết dữ liệu nào bạn nên truy xuất và dữ liệu đó làm gì với dữ liệu đó.

0

Kiểm tra đơn vị là các thử nghiệm mà mã được kiểm tra nằm trong lớp thực tế. Một phụ thuộc khác của lớp này được mô phỏng hoặc bỏ qua, vì trọng tâm là kiểm tra mã bên trong lớp.

Kiểm tra tích hợp là các thử nghiệm liên quan đến truy cập đĩa, dịch vụ ứng dụng và/hoặc khung từ ứng dụng đích. Các thử nghiệm tích hợp chạy bị cô lập từ các dịch vụ khác.

Tôi sẽ đưa ra một ví dụ. Bạn có một ứng dụng Spring và bạn đã thực hiện rất nhiều bài kiểm tra đơn vị để đảm bảo rằng logic nghiệp vụ hoạt động đúng. Hoàn hảo. Nhưng những loại xét nghiệm, bạn phải đảm bảo:

  • dịch vụ ứng dụng của bạn có thể bắt đầu
  • tổ chức cơ sở dữ liệu của bạn được ánh xạ một cách chính xác
  • Bạn có tất cả các chú thích cần thiết làm việc như mong đợi
  • Bộ lọc của bạn đang hoạt động bình thường
  • API của bạn đang chấp nhận một số loại dữ liệu
  • Tính năng chính của bạn là thực sự làm việc trong kịch bản cơ bản
  • truy vấn cơ sở dữ liệu của bạn đang làm việc như mong đợi
  • Etc ...

này không thể được thực hiện với các bài kiểm tra đơn vị nhưng bạn (tốt, mùa xuân Slice có thể làm một số trong số họ ...), như nhà phát triển, bạn cũng cần đảm bảo điều đó. Đây là vai trò của các bài kiểm tra tích hợp.

Kịch bản lý tưởng là các thử nghiệm tích hợp chạy độc lập với các hệ thống khác mà ứng dụng có thể sử dụng trong môi trường sản xuất (sử dụng Wiremock for Rest calls, cơ sở dữ liệu bộ nhớ, v.v.).

Một chút tò mò: Maven có một plugin cụ thể cho Kiểm tra tích hợp: maven failsafe plugin thực hiện các lớp kiểm tra mà tên kết thúc bằng CNTT. Ví dụ: UserIT.java.

Sự nhầm lẫn về những gì tích hợp thử nghiệm có nghĩa

Một số người hiểu được "thử nghiệm hội nhập" như một bài kiểm tra liên quan đến việc "hội nhập" với các hệ thống khác mà hiện nay sử dụng hệ thống. Loại xét nghiệm này chỉ có thể được thực hiện trong một môi trường nơi bạn có tất cả các hệ thống này để tham dự.

Đây có thể chỉ là vấn đề đặt tên, nhưng chúng tôi thiếu kiểm tra (những gì tôi hiểu là kiểm tra tích hợp) cảm thấy sự cần thiết của các mục được mô tả ở trên. Ngược lại, chúng tôi đang nhảy cho một định nghĩa của các bài kiểm tra đơn vị (chỉ lớp thử nghiệm) cho một bài kiểm tra tích hợp (toàn bộ hệ thống thực). Những gì là ở giữa nếu không phải là các bài kiểm tra tích hợp?

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