Tăng khả năng thử nghiệm, khi mã hóa bằng Bold cho khung Delphi

Question

Nền Tôi làm việc trong một nhóm gồm 7 nhà phát triển và 2 người kiểm tra hoạt động trên hệ thống hậu cần. Chúng tôi sử dụng Delphi 2007 và modeldriven phát triển với khuôn khổ Bold for Delphi. Hệ thống đã được sản xuất khoảng 7 năm nay và có khoảng 1,7 triệu dòng mã. Chúng tôi phát hành sản xuất sau 4-5 tuần và sau hầu hết mọi bản phát hành, chúng tôi phải thực hiện một số bản vá lỗi cho các lỗi mà chúng tôi không tìm thấy. Điều này tất nhiên gây khó chịu cho cả chúng tôi và khách hàng.

Thử nghiệm hiện tại Giải pháp dĩ nhiên là thử nghiệm tự động hơn. Hiện tại chúng tôi có kiểm tra thủ công. Một Testdbgenerator bắt đầu với một cơ sở dữ liệu rỗng và thêm dữ liệu từ các phương thức được mô hình hoá. Chúng tôi cũng có Testcomplete chạy một số tập lệnh rất cơ bản để kiểm tra GUI. Thiếu thời gian ngăn chúng tôi thêm các kiểm tra khác, nhưng các tập lệnh cũng nhạy cảm với những thay đổi trong ứng dụng. Đối với một số năm trước, tôi thực sự đã thử nghiệm đơn vị với DUnit, nhưng tôi đã từ bỏ sau một vài ngày. Các đơn vị có kết nối quá mạnh.

điều kiện tiên quyết Đơn vị kiểm tra Tôi nghĩ rằng tôi biết một số điều kiện tiên quyết cho kiểm tra đơn vị:

• Viết phương pháp nhỏ mà làm một chuyện, nhưng làm điều đó tốt.
• Đừng lặp lại chính mình.
• Trước tiên hãy viết bài kiểm tra không thành công, sau đó viết mã để vượt qua bài kiểm tra.
• Các kết nối giữa các đơn vị bị bung lỏng. Họ không nên biết nhiều về nhau.
• Sử dụng tính năng tiêm phụ thuộc.

Framework để sử dụng Chúng tôi có thể nâng cấp lên Delphi XE2, chủ yếu là do trình biên dịch 64-bit. Tôi đã xem Spring một chút nhưng điều này yêu cầu cập nhật từ D2007 và điều đó sẽ không xảy ra ngay bây giờ. Có thể năm sau.

Câu hỏi Hầu hết mã vẫn không được kiểm tra tự động. Vậy con đường nào tốt nhất để tăng khả năng kiểm tra mã cũ? Hoặc có lẽ tốt nhất là bắt đầu viết các bài kiểm tra cho các phương thức mới? Tôi không chắc chắn cách tốt nhất để tăng thử nghiệm tự động và nhận xét về nó là gì. Chúng ta có thể sử dụng D2007 + DUnit bây giờ và sau đó dễ dàng chuyển sang Delphi XE2 + Spring sau đó không?

CHỈNH SỬA: Giới thiệu về phương pháp thử nghiệm hiện tại để kiểm tra thủ công chỉ là "pound vào nó và cố gắng phá vỡ nó" là Chris gọi nó.

Answer 1

Bạn muốn sách của Michael Feathers, Working Effectively with Legacy Code. Nó cho thấy làm thế nào để giới thiệu (đơn vị) kiểm tra mã mà không được viết với testability trong tâm trí.

Một số chương được đặt tên cho lý do một nhà phát triển có thể cung cấp cho lý do tại sao kiểm tra mã cũ là khó khăn, và chúng chứa các nghiên cứu trường hợp và đề nghị cách để giải quyết từng vấn đề:

• Tôi không có nhiều thời gian và tôi phải thay đổi nó
• tôi không thể chạy phương pháp này trong một khai thác thử nghiệm
• lớp này là quá lớn và tôi không muốn nó nhận được bất kỳ lớn hơn
• tôi cần phải thay đổi một phương pháp quái vật và Tôi không thể viết các bài kiểm tra cho nó.

Nó cũng bao gồm nhiều kỹ thuật để phá vỡ các phụ thuộc; một số có thể là mới đối với bạn, và một số bạn có thể đã biết nhưng chưa nghĩ đến việc sử dụng.

Answer 2

Nhóm thử nghiệm của bạn quá nhỏ, IMO. Tôi đã từng làm việc trong các đội, nơi QA chiếm ưu thế hơn các nhà phát triển. Xem xét làm việc trong "chạy nước rút" của khối có thể quản lý (tính năng, bản sửa lỗi) phù hợp với các chu kỳ nhỏ hơn. "Agile" sẽ khuyến khích chạy nước rút trong 2 tuần, nhưng điều đó có thể quá chặt chẽ. Dù sao, nó sẽ giữ cho QA liên tục bận rộn, làm việc xa hơn trước cửa sổ phát hành. Ngay bây giờ, tôi nghi ngờ rằng họ đang nhàn rỗi cho đến khi bạn cung cấp cho họ một số lượng lớn mã, sau đó họ đang đầm lầy. Với chu kỳ phát hành ngắn hơn, bạn có thể giữ nhiều người thử nghiệm bận rộn hơn.

Ngoài ra, bạn không nói nhiều về phương pháp thử nghiệm của họ.Họ có các kịch bản tiêu chuẩn mà họ chạy, nơi họ xác minh sự xuất hiện và hành vi chống lại sự xuất hiện và hành vi dự kiến? Hay họ chỉ "đập vào nó và cố gắng phá vỡ nó"?

IMO, kiểm tra Dunit khó thực hiện với nhiều phụ thuộc như cơ sở dữ liệu, giao tiếp, v.v. Nhưng nó có thể thực hiện được. Tôi đã tạo ra các lớp DUnit tự động chạy các kịch bản thiết lập cơ sở dữ liệu (tìm một tệp .sql có cùng tên với lớp đang được thử nghiệm, chạy sql, sau đó tiến hành kiểm tra) và nó rất hiệu quả. Đối với truyền thông SOAP, tôi có một SoapUI mockservice chạy để trả về kết quả đóng hộp, vì vậy tôi có thể kiểm tra thông tin liên lạc của tôi.
Nó không hoạt động, nhưng nó có giá trị.

Answer 3

Các yêu cầu cho kiểm tra đơn vị tự động chính xác này:

1. sử dụng một khuôn khổ kiểm tra đơn vị (ví dụ, Dunit).
2. sử dụng một số loại khung mocking.

Mục 2 là điều khó khăn nhất.

KHÔ, phương pháp nhỏ, bắt đầu bằng thử nghiệm và DI là tất cả đường. Trước tiên, bạn cần phải bắt đầu thử nghiệm đơn vị. Thêm DRY, v.v. khi bạn đi cùng. Khớp nối giảm giúp làm cho công cụ dễ dàng hơn đơn vị được thử nghiệm, nhưng không có nỗ lực tái cấu trúc khổng lồ, bạn sẽ không bao giờ giảm khớp nối trong cơ sở mã hiện có của mình.

Cân nhắc viết bài kiểm tra cho những nội dung mới và nội dung được thay đổi trong bản phát hành. Theo thời gian, bạn sẽ nhận được một cơ sở hợp lý các bài kiểm tra đơn vị. Công cụ mới và thay đổi cũng có thể được tái cấu trúc (hoặc được viết độc đáo).

Ngoài ra, hãy xem xét quy trình xây dựng tự động chạy kiểm tra đơn vị và gửi email khi quá trình xây dựng bị gián đoạn.

Điều này chỉ bao gồm kiểm tra đơn vị. Đối với người kiểm tra QA, bạn sẽ cần một công cụ (chúng tồn tại, nhưng tôi không thể nghĩ ra bất kỳ công cụ nào) cho phép chúng chạy thử nghiệm tự động (không phải là các kiểm thử đơn vị).