Làm thế nào tôi nên kiểm tra đơn vị một lớp dựa trên việc có dữ liệu thực tế?

Tôi có một lớp học gói gọn các kết quả của một phép đo khoa học. Tôi đang xây dựng các bài kiểm tra đơn vị ngay từ đầu, nhưng tôi không có nhiều kinh nghiệm về kiểm thử đơn vị và tôi không chắc mình nên kiểm tra những hành vi nào và làm thế nào.

Lớp tôi làm ba loại:

1. Đọc dữ liệu đo từ một tệp (hoặc chuỗi) vào các biến thể hiện của nó
2. Ghi dữ liệu đo lường của nó ra một tệp hoặc một chuỗi
3. Thực hiện các phép tính trên dữ liệu của nó (ví dụ: lấy trung bình của một bộ số)

Cách tiếp cận của tôi ngay bây giờ là bao gồm một tệp dữ liệu ví dụ nổi tiếng trong testthư mục của tôi . Một bài kiểm tra đọc dữ liệu từ tệp, chuyển nó đến lớp của tôi và đảm bảo rằng nó đáp ứng một số kiểm tra vệ sinh cơ bản. Một thử nghiệm khác chuyển tên tệp của tệp đến lớp của tôi, cho phép lớp đọc nó và chạy các thử nghiệm tương tự. Phần còn lại của các bài kiểm tra đọc dữ liệu từ tệp, chuyển nó đến lớp của tôi và kiểm tra xem kết quả của các phương pháp xử lý dữ liệu có chính xác hay không, dựa trên những gì tôi biết về tập dữ liệu đó.

Điều này có vẻ khá rối, mặc dù. Các thử nghiệm kiểm tra (3) mặc nhiên cho rằng các hành vi của (1) là chính xác, vì đó là các hàm trong (1) đang được sử dụng để đưa vào lớp ngay từ đầu. Và các thử nghiệm của (1) có thể được hưởng lợi từ các kiểm tra mở rộng được thực hiện bởi các thử nghiệm cho (3). Tôi có cấu trúc bài kiểm tra đơn vị của mình kém hay đây chỉ là kết quả tự nhiên của thực tế là tôi cần sử dụng một tập dữ liệu cụ thể trong các bài kiểm tra của mình?

Những gì bạn đang làm là kiểm thử tích hợp, vì như bạn có thể nói, các kiểm tra của bạn có sự phụ thuộc vào các phần khác trong mã của bạn. Điều này tốt, nhưng thật tốt khi biết bạn đang xem bài viết / ví dụ / v.v. Trực tuyến.

Một số điểm cần xem xét và những điều cần nhớ:

• Sắp xếp , hành động , khẳng định . Tất cả các bài kiểm tra có 3 bước này.
  • Cần nhiều bước hơn? Có lẽ bạn đang kiểm tra quá nhiều cho 1 bài kiểm tra
  • Không sắp xếp? Bạn có các phụ thuộc bên ngoài, điều này hầu như luôn làm cho các bài kiểm tra dễ bị lung lay và không đáng tin cậy.
  • Rất nhiều mã Sắp xếp thường có nghĩa là rất nhiều phụ thuộc và các loại phụ thuộc trạng thái hệ thống. Đó là một công thức cho mã dễ vỡ.
  • Không có đạo luật? Thường kiểm tra trình biên dịch. Để lại đó cho các nhà phát triển trình biên dịch.
  • Rất nhiều Đạo luật? Có lẽ bạn đang kiểm tra quá nhiều cho 1 lần kiểm tra lại.
  • Không khẳng định? Thông thường trường hợp khi bạn muốn kiểm tra rằng "không có lỗi xảy ra". Không có lỗi! = Làm việc chính xác.
  • Rất nhiều khẳng định? Mã được kiểm tra có thể làm quá nhiều / chạm vào quá nhiều hệ thống. Thay vào đó, hãy thử tái cấu trúc và kiểm tra các bit riêng lẻ.
• Các xét nghiệm nên tự tồn tại. Tránh các tình huống trong đó một cái gì đó kiểm tra 3 phụ thuộc vào mã làm 1 . Thay vào đó, hãy tìm cách thay thế mã làm 1 bằng mã kiểm tra. Trong kịch bản của bạn: thử đặt thủ công các giá trị thành giá trị bạn muốn trong bước Sắp xếp của bài kiểm tra , sau đó thực hiện ion Act (tính toán), sau đó Xác nhận kết quả.
• Các bài kiểm tra đường hạnh phúc thường lãng phí thời gian. Kịch bản trường hợp tốt nhất hầu như luôn luôn làm việc. Các bài kiểm tra của bạn nên cố gắng buộc các lỗi và trường hợp cạnh.
  • Bạn có một bài kiểm tra vượt qua các luồng xấu để được xử lý?
  • Bạn có một bài kiểm tra vượt qua tên tập tin null / không tồn tại để được xử lý?
  • Điều gì xảy ra nếu các giá trị số để tính toán không phải là số hoặc khi được phân tích cú pháp là rất lớn hoặc tạo ra các giá trị lớn khi được tính toán?
• Đáng ngạc nhiên là các bài kiểm tra viết hiếm khi xác nhận rằng những gì bạn đã làm là đúng. Thay vào đó họ cung cấp cho bạn cái nhìn sâu sắc về cách thiết kế có thể sử dụng, ổn định và linh hoạt của bạn.

chỉnh sửa> Điều này đã được chấp nhận, nhưng tôi muốn thêm một cái gì đó mà tôi đã học được từ lâu thông qua Kiểm tra đơn vị thực dụng :

Kiểm tra đơn vị với BICEP phải của bạn

• Kết quả có đúng không?
• Điều kiện biên ĐÚNG B
  • C onform đến định dạng mong đợi
  • O rdered chính xác
  • R ange là đúng
  • R hội nghị để phụ thuộc bên ngoài là an toàn
  • E xistence (null, vv)
  • C trọng tài
  • T iming (mọi thứ xảy ra theo đúng thứ tự, với thời gian chính xác)
• Tôi quan hệ
• C ross-Kiểm tra kết quả với các phương tiện khác
• Gương E bị ép
• Đặc điểm độ chính xác P nằm trong giới hạn cho phép

Tôi nghĩ rằng lớp học của bạn khó kiểm tra vì nó có quá nhiều trách nhiệm. Bạn tự đề cập đến họ

• Đọc dữ liệu từ tập tin
• Ghi dữ liệu vào tập tin
• Thực hiện tính toán

Lý tưởng nhất, một lớp nên có một trách nhiệm duy nhất, hoặc một lĩnh vực trách nhiệm duy nhất. Trong trường hợp này, bạn chắc chắn nên có một lớp chỉ chứa logic để thực hiện các phép tính.

Nếu bạn có điều đó, có lẽ bạn có thể có một chức năng như thế này:

CalculationResult PerformCalculation(Measurement[] measurements)
{ ... }

Điều này trở nên tương đối dễ kiểm tra, vì bạn có thể dễ dàng cung cấp một loạt các phép đo được xác định rõ trong một thử nghiệm.

Tôi giả sử ở đây rằng bạn đọc từ tệp một lần để có được tất cả các phép đo cùng một lúc. Nếu bạn thu thập các phép đo mới được ghi vào tệp theo thời gian, lớp của bạn có thể trông như thế này:

class Calculator {
    AddMeasurement(Measurement measurement) { ... }

    CalculationResult PerformCalculation() { ... }
}

Vẫn dễ kiểm tra, bởi vì bạn có thể cung cấp cho lớp với một loạt các phép đo được xác định rõ trong quá trình kiểm tra và đọc kết quả mà không cần phụ thuộc vào hệ thống tệp.

Một lớp khác có thể có trách nhiệm đọc dữ liệu Đo lường từ tệp. Điều này một lần nữa có thể được phân chia thành đọc dữ liệu từ một tệp và phân tích dữ liệu dưới dạng các đối tượng Đo lường, để cho phép kiểm tra logic phân tích cú pháp riêng mà không phụ thuộc vào hệ thống tệp, v.v.

Nếu khó viết bài kiểm tra đơn vị, đây thường là dấu hiệu cho thấy "đơn vị" của bạn có nhiều trách nhiệm, quá nhiều phụ thuộc hoặc theo các cách khác không phải là RẮN .

Kiểm tra đơn vị nên kiểm tra hai bộ trường hợp:

Các trường hợp rất cơ bản: là tính toán chính xác, thực hiện tổng cộng, v.v ... Sử dụng đơn giản dễ dàng để kiểm tra dữ liệu cho các trường hợp này.

Các trường hợp cạnh: ngày giao hàng ngày 29 tháng 2 năm 2016, Số lượng đặt hàng 999.999, Các mặt hàng có giá $ 0,00, GPS cho Bắc Cực (thử di chuyển về phía tây!), V.v.

Tôi nghĩ rằng nhiều câu trả lời là đúng, theo nghĩa là có quá nhiều bài kiểm tra thiết yếu dường như chúng được kết hợp thành một ví dụ kiểm tra đơn vị. NHƯNG.

Nhiều chức năng yêu cầu dữ liệu phức tạp và tạo ra kết quả phức tạp. Xử lý ảnh, ví dụ, có thể có chức năng nhỏ gọn tạo ra mặt nạ từ ảnh. Trình điều khiển thử nghiệm (tôi sẽ tranh luận, thích hợp) sẽ đọc một hình ảnh, xử lý nó, viết một tệp hình ảnh và so sánh tệp kết quả với một tệp hình ảnh tham chiếu.

Kiểm tra sự tích hợp trong mục tiêu của tất cả các chức năng đó sẽ là một thử nghiệm tích hợp. Kiểm tra một chức năng duy nhất của mục tiêu của bạn, một đầu vào phức tạp đến đầu ra phức tạp, là một thử nghiệm đơn vị thích hợp.