Các xét nghiệm TDD dạng hạt nên như thế nào?

Trong quá trình đào tạo TDD dựa trên trường hợp phần mềm y tế, chúng tôi đang thực hiện câu chuyện sau: "Khi người dùng nhấn nút Lưu, hệ thống nên thêm bệnh nhân, thêm thiết bị và thêm hồ sơ dữ liệu thiết bị".

Việc thực hiện cuối cùng sẽ trông giống như thế này:

if (_importDialog.Show() == ImportDialogResult.SaveButtonIsPressed)
{
   AddPatient();
   AddDevice();
   AddDeviceDataRecords();
}

Chúng tôi có hai cách để thực hiện nó:

1. Ba thử nghiệm trong đó mỗi thử nghiệm xác minh một phương thức (AddPatient, AddDevice, AddDeviceDataRecords) đã được gọi
2. Một thử nghiệm xác minh cả ba phương thức được gọi

Trong trường hợp đầu tiên nếu có điều gì đó sai xảy ra nếu điều kiện mệnh đề, cả ba bài kiểm tra sẽ thất bại. Nhưng trong trường hợp thứ hai nếu thử nghiệm thất bại, chúng tôi không chắc chắn chính xác những gì sai. Bạn thích cách nào

Nhưng trong trường hợp thứ hai nếu thử nghiệm thất bại, chúng tôi không chắc chắn chính xác những gì sai.

Tôi nghĩ rằng điều đó phần lớn phụ thuộc vào mức độ thông báo lỗi mà bài kiểm tra tạo ra. Nói chung, có nhiều cách khác nhau để xác minh rằng một phương thức đã được gọi; ví dụ: nếu bạn sử dụng một đối tượng giả, nó sẽ cung cấp cho bạn một thông báo lỗi chính xác mô tả phương thức dự kiến ​​nào không được gọi trong quá trình thử nghiệm. Nếu bạn xác minh rằng phương thức đã được gọi thông qua việc cảm nhận các hiệu ứng của cuộc gọi, thì bạn phải tạo ra một thông báo lỗi mô tả.

Trong thực tế, sự lựa chọn giữa lựa chọn 1 và 2 cũng phụ thuộc vào tình huống. Nếu tôi thấy mã bạn hiển thị ở trên trong một dự án cũ, tôi chọn cách tiếp cận thực tế của Trường hợp # 2 chỉ để xác minh rằng mỗi trong số 3 phương thức được gọi đúng khi điều kiện được đáp ứng. Nếu tôi đang phát triển đoạn mã này ngay bây giờ, 3 lệnh gọi phương thức rất có thể sẽ được thêm từng cái một, tại các thời điểm riêng biệt (có thể là ngày hoặc tháng cách xa nhau), vì vậy tôi sẽ thêm một bài kiểm tra đơn vị mới, riêng biệt để xác minh từng cuộc gọi.

Cũng lưu ý rằng, dù bằng cách nào, bạn cũng nên có các bài kiểm tra đơn vị riêng biệt để xác minh rằng mỗi phương thức riêng lẻ làm những gì nó phải làm.

Độ chi tiết trong ví dụ của bạn dường như là sự khác biệt giữa các bài kiểm tra đơn vị và chấp nhận.

Một đơn vị kiểm tra đơn giản nhất của chức năng, với càng ít phụ thuộc càng tốt. Trong trường hợp của bạn, có thể có 4 unittest

• AddPatient có thêm một bệnh nhân (nghĩa là gọi các hàm cơ sở dữ liệu có liên quan) không?
• AddDevice có thêm thiết bị không?
• AddDeviceDataRecords có thêm các bản ghi không?
• chức năng chính unamend trong ví dụ của bạn gọi AddPatient, AddDevice và AddDeviceFifts

Unittests dành cho các nhà phát triển , vì vậy họ có được sự tin tưởng, rằng mã của họ là đúng về mặt kỹ thuật

Các thử nghiệm chấp nhận nên kiểm tra chức năng kết hợp, từ quan điểm của người dùng. Chúng nên được mô hình hóa theo các câu chuyện của người dùng và ở mức độ cao nhất có thể. Vì vậy, bạn không phải kiểm tra xem các chức năng có được gọi hay không, nhưng nếu đạt được lợi ích cho người dùng :

Khi người dùng nhập dữ liệu, nhấp vào ok và ...

• ... vào danh sách bệnh nhân, anh ta sẽ gặp một bệnh nhân mới với tên được đặt
• ... vào danh sách thiết bị, anh ta sẽ thấy một thiết bị mới
• ... đi đến chi tiết của thiết bị mới, anh ta sẽ thấy các bảng dữ liệu mới

kiểm tra chấp nhận là dành cho khách hàng , hoặc, để xây dựng một giao tiếp tốt hơn với họ.

Để trả lời câu hỏi của bạn "bạn muốn gì hơn": vấn đề lớn hơn đối với bạn ngay bây giờ là gì, lỗi và hồi quy (=> nhiều hơn không đáng tin) hoặc hiểu và chính thức hóa bức tranh lớn (=> nhiều bài kiểm tra chấp nhận hơn)

Chúng tôi có hai cách để thực hiện nó:

Điều đó là sai.

Ba thử nghiệm trong đó mỗi thử nghiệm xác minh một phương thức (AddPatient, AddDevice, AddDeviceDataRecords) đã được gọi

Bạn phải làm điều này để chắc chắn rằng nó hoạt động.

Một thử nghiệm xác minh cả ba phương thức được gọi

Bạn cũng phải làm điều này để đảm bảo API hoạt động.

Lớp học - như một đơn vị - phải được kiểm tra hoàn toàn. Mỗi phương pháp.

Bạn có thể bắt đầu với một bài kiểm tra bao gồm cả ba phương pháp, nhưng nó không cho bạn biết nhiều.

nếu thử nghiệm thất bại, chúng tôi không chắc chắn chính xác những gì sai.

Chính xác. Đó là lý do tại sao bạn kiểm tra tất cả các phương pháp.

Bạn phải kiểm tra giao diện công cộng. Vì lớp này thực hiện ba cộng một điều (ngay cả khi chúng được gói trong một phương thức vì câu chuyện của người dùng), bạn phải kiểm tra tất cả bốn điều. Ba cấp thấp và một bó.

Chúng tôi viết các bài kiểm tra đơn vị của chúng tôi cho các câu có ý nghĩa về chức năng , nhiều lần ánh xạ tới một phương thức (nếu bạn đã viết mã của mình tốt), nhưng đôi khi trở nên lớn hơn, bao gồm nhiều phương thức.

Ví dụ, hãy tưởng tượng rằng việc thêm một bệnh nhân vào hệ thống của bạn cần một số chương trình con (hàm con) để được gọi:

1. ConfirmPatientQualification
2. SureDoctorExistence
3. CheckInsuranceHistory
4. SureEmptyBed

Chúng tôi cũng có thể viết bài kiểm tra đơn vị cho từng chức năng này.

Một nguyên tắc đơn giản mà tôi đã tuân theo là đặt tên cho bài kiểm tra để nó mô tả chính xác những gì bài kiểm tra thực hiện. Nếu tên của bài kiểm tra trở nên quá phức tạp thì đó là dấu hiệu cho thấy bài kiểm tra có thể làm quá nhiều. Vì vậy, ví dụ, đặt tên một bài kiểm tra để thực hiện những gì bạn đề xuất trong tùy chọn 2 có thể trông giống như PatientIsAddedDeviceIsAddedAndDeviceDataRecordsWhenSatted phức tạp hơn nhiều so với ba bài kiểm tra riêng biệt PatientIsAddedWhenSatted, DeviceIsAddedWhenSatted Tôi cũng nghĩ rằng những bài học có thể học được từ BDD khá thú vị khi mỗi bài kiểm tra thực sự đại diện cho một yêu cầu duy nhất có thể được mô tả bằng ngôn ngữ tự nhiên.