Chúng ta có cần dữ liệu kiểm tra hay chúng ta có thể dựa vào kiểm tra đơn vị và kiểm tra thủ công?

Chúng tôi hiện đang làm việc trên một dự án PHP / MySQL vừa / lớn. Chúng tôi đang thực hiện kiểm tra đơn vị với PHPUnit & QUnit và chúng tôi có hai trình kiểm tra toàn thời gian đang kiểm tra ứng dụng theo cách thủ công. Dữ liệu thử nghiệm (giả) của chúng tôi hiện được tạo bằng các tập lệnh SQL.

Chúng tôi có vấn đề với việc duy trì các tập lệnh cho dữ liệu thử nghiệm. Logic nghiệp vụ khá phức tạp và một thay đổi "đơn giản" trong dữ liệu thử nghiệm thường tạo ra một số lỗi trong ứng dụng (không phải là lỗi thực sự, chỉ là sản phẩm của dữ liệu không hợp lệ). Điều này đã trở thành gánh nặng lớn cho toàn đội vì chúng tôi liên tục tạo và thay đổi bảng.

Tôi thực sự không thấy điểm duy trì dữ liệu thử nghiệm trong các tập lệnh bởi vì mọi thứ có thể được thêm thủ công vào ứng dụng trong khoảng 5 phút với giao diện người dùng. Thủ tướng của chúng tôi không đồng ý và nói rằng có dự án mà chúng tôi không thể triển khai với dữ liệu thử nghiệm là một thực tiễn tồi.

Chúng ta có nên từ bỏ việc bảo trì các tập lệnh với dữ liệu thử nghiệm và chỉ để cho những người thử nghiệm thử nghiệm ứng dụng mà không có dữ liệu? Thực hành tốt nhất là gì?

Bạn đang trộn hai khái niệm khác nhau. Một là xác minh , dựa trên Kiểm tra đơn vị và Đánh giá ngang hàng. Điều này có thể được thực hiện bởi chính các nhà phát triển, không có dữ liệu thử nghiệm và mục đích của nó là xác minh rằng một loạt các yêu cầu được đáp ứng.

Cái thứ hai là xác nhận , và điều này được thực hiện bởi QA (người thử nghiệm của bạn). Đối với bước này, bạn cần có dữ liệu kiểm tra vì người kiểm tra không cần có bất kỳ kiến ​​thức nào về lập trình trong ứng dụng, chỉ có các trường hợp sử dụng dự định của nó. Mục tiêu của nó là xác nhận rằng ứng dụng hoạt động như dự định trong môi trường sản xuất.

Cả hai quy trình đều quan trọng và cần thiết để cung cấp một sản phẩm chất lượng cho khách hàng. Bạn không thể chỉ dựa vào các bài kiểm tra đơn vị. Những gì bạn cần tìm ra là một cách đáng tin cậy để xử lý dữ liệu thử nghiệm của bạn để đảm bảo tính hợp lệ của nó.

EDIT: OK, tôi hiểu những gì bạn đang yêu cầu. Câu trả lời là có, bởi vì công việc của Người kiểm tra không phải là tạo dữ liệu thử nghiệm, chỉ để kiểm tra ứng dụng. Bạn cần xây dựng các tập lệnh của mình theo cách cho phép bảo trì dễ dàng hơn và đảm bảo dữ liệu hợp lệ được chèn vào. Không có dữ liệu kiểm tra, người kiểm tra sẽ không có gì để kiểm tra. Tuy nhiên, đã nói rằng, nếu bạn có quyền truy cập vào môi trường thử nghiệm , tôi không hiểu lý do tại sao bạn không thể chèn dữ liệu kiểm tra theo cách thủ công thay vì sử dụng tập lệnh.

Có, có các bài kiểm tra đơn vị và mô phỏng dữ liệu là một cách thực hành tốt nhất. Người quản lý dự án là chính xác. Vì việc thực hiện thay đổi "đơn giản" trong dữ liệu thử nghiệm thường tạo ra lỗi, nên đó là cốt lõi của vấn đề.

Các mã cần cải thiện. Không làm như vậy (nói rằng chúng tôi không cần kiểm tra) không phải là một sửa chữa, đó chỉ đơn giản là thêm nợ kỹ thuật . Chia mã thành các đơn vị có thể kiểm tra nhỏ hơn vì không thể xác định đơn vị mà không bị hỏng là một vấn đề.

Bắt đầu làm một refactor. Giữ những cải tiến nhỏ để chúng có thể quản lý được. Tìm kiếm các mô hình chống như các lớp / phương thức của Chúa, không tuân theo DRY, trách nhiệm đơn lẻ, v.v ...

Cuối cùng, nhìn vào TDD để xem nó có hoạt động cho nhóm không. TDD hoạt động tốt để đảm bảo tất cả mã của bạn đều có thể kiểm tra được (vì bạn viết các bài kiểm tra trước) và cũng đảm bảo bạn giữ vững tinh thần bằng cách viết mã vừa đủ để vượt qua các bài kiểm tra (giảm thiểu kỹ thuật).

Nói chung, nếu một loạt các quy trình logic kinh doanh phức tạp tạo ra một tập hợp dữ liệu, thì tôi xem đây là một báo cáo. Đóng gói báo cáo. Chạy báo cáo và sử dụng đối tượng kết quả làm đầu vào cho bài kiểm tra tiếp theo.

Đây là một vấn đề rất phổ biến và cũng rất khó khăn. Các kiểm tra tự động chạy trên cơ sở dữ liệu (ngay cả cơ sở dữ liệu trong bộ nhớ, chẳng hạn như HSQLDB ) thường chậm, không xác định và do lỗi kiểm tra chỉ cho thấy có vấn đề ở đâu đó trong mã của bạn hoặc trong dữ liệu của bạn, chúng là không nhiều thông tin.

Theo kinh nghiệm của tôi, chiến lược tốt nhất là tập trung vào các bài kiểm tra đơn vị cho logic kinh doanh. Cố gắng bao gồm càng nhiều càng tốt mã miền cốt lõi của bạn. Nếu bạn thực hiện đúng phần này, đây là một thách thức khá lớn, bạn sẽ đạt được mối quan hệ lợi ích chi phí tốt nhất cho các bài kiểm tra tự động. Đối với lớp kiên trì, tôi thường đầu tư ít nỗ lực hơn vào các bài kiểm tra tự động và để nó cho người kiểm tra thủ công chuyên dụng.

Nhưng nếu bạn thực sự muốn (hoặc cần) tự động hóa các bài kiểm tra tính bền bỉ, tôi khuyên bạn nên đọc Phần mềm hướng đối tượng phát triển, được hướng dẫn bởi các bài kiểm tra . Cuốn sách này có cả một chương dành riêng cho các bài kiểm tra kiên trì.