Phpunit Laravel
TL;DR. Trong hướng dẫn này, chúng ta sẽ tìm hiểu cách xây dựng và kiểm tra các điểm cuối khác nhau của API RESTful được tạo bằng Laravel. Cách tiếp cận của chúng tôi để đạt được điều này sẽ bao gồm Show
Chúng tôi sẽ thực hiện việc này dần dần theo thứ tự thời gian cho từng điểm cuối API đã xác định. Bạn có thể tìm thấy mã nguồn hoàn chỉnh cho hướng dẫn này tại đây trên GitHub Là một kỹ sư phần mềm đang cân nhắc việc phát triển thêm một bước nữa (và bạn nên làm điều đó), phát triển dựa trên thử nghiệm, thường được gọi là TDD, là một trong những phương pháp hay nhất mà bạn có thể thêm vào kho vũ khí của mình. Để kiểm tra rõ ràng các ứng dụng của bạn, Laravel được cài đặt sẵn PHPUnit, một khung kiểm tra cho PHP. Nó chứa các phương thức trợ giúp thuận tiện hữu ích để tạo và chạy các tập lệnh kiểm tra được viết riêng cho các đơn vị khác nhau trong ứng dụng của bạn điều kiện tiên quyếtKiến thức hợp lý về lập trình hướng đối tượng với PHP sẽ giúp bạn tận dụng tốt nhất hướng dẫn này. Trong suốt hướng dẫn, tôi sẽ cố gắng hết sức để giải thích các khái niệm về Laravel mà tôi nêu ra và cung cấp các liên kết để nghiên cứu thêm. Vui lòng tạm dừng và xem qua chúng nếu bạn bị lạc bất cứ lúc nào - Tôi hứa rằng hướng dẫn này sẽ vẫn ở đây khi bạn quay lại Môi trường phát triển của bạn cũng sẽ cần đáp ứng các yêu cầu máy chủ do Laravel đặt ra - bao gồm cài đặt toàn cầu Composer Bạn có thể thiết lập các dự án Laravel mới bằng Trình soạn thảo hoặc Trình cài đặt Laravel Trong hướng dẫn này, chúng tôi sẽ sử dụng PHPUnit và Xdebug để thử nghiệm và phân tích mức độ phù hợp. Vui lòng đảm bảo rằng bạn đã cài đặt Xdebug trên hệ thống của mình Tầm quan trọng của thử nghiệmTầm quan trọng của thử nghiệm bắt nguồn từ hai điều - đảm bảo và khả năng bảo trì Internet tràn ngập những câu chuyện về lỗi phần mềm khiến các tổ chức thiệt hại hàng triệu đô la. Có một chủ đề chung giữa tất cả những câu chuyện này - thử nghiệm không đầy đủ. Không có thử nghiệm nào được thực hiện hoặc các thử nghiệm không bao gồm đầy đủ tất cả các tình huống tiềm ẩn mà ứng dụng sẽ gặp phải. Là nhà phát triển, chúng tôi có xu hướng mô hình hóa các ứng dụng của mình xung quanh các kịch bản lý tưởng nhưng môi trường sản xuất thì không lý tưởng. Việc kiểm tra của chúng tôi bao gồm TẤT CẢ các tình huống có thể xảy ra và đảm bảo rằng ứng dụng của chúng tôi hoạt động theo cách mong đợi trong tất cả các tình huống đó là điều cực kỳ quan trọng Vấn đề về khả năng bảo trì được xây dựng dựa trên sự đảm bảo. Bạn đã bao giờ nhìn vào một đoạn mã và nghĩ đến việc cấu trúc lại nó, nhưng lại chần chừ vì sợ làm hỏng ứng dụng chưa? . Đây là cách mã bắt đầu hoạt động (theo lời của chú Bob) và các lỗi xuất hiện. Một thay đổi vi phạm được thực hiện trong một lớp nhưng không trùng lặp trong một lớp khác. Ứng dụng thực chất trở thành quả bom hẹn giờ chờ phát nổ. Ngoài ra, thử nghiệm thích hợp làm cho các quy trình như CI/CD trở nên đáng tin cậy hơn — giúp phát hành các bản cập nhật một cách nhanh chóng. Không cần phải nói, người ta không thể đánh giá quá cao tầm quan trọng của thử nghiệm Hướng phát triển thử nghiệmTest Driven Development (TDD) là một phong cách lập trình dựa trên ba trụ cột. thử nghiệm, mã hóa và thiết kế (tái cấu trúc). TDD hơi bất thường đối với trải nghiệm của nhà phát triển thông thường theo nghĩa là chúng tôi có xu hướng viết mã trước khi thực hiện các trường hợp thử nghiệm của mình. Tuy nhiên, điều này ảnh hưởng đến chất lượng của các trường hợp thử nghiệm của chúng tôi, vì các thử nghiệm của chúng tôi sẽ được hướng dẫn bởi mã của chúng tôi (chỉ xử lý các điều kiện lý tưởng) Ngoài ra, khi viết mã trước, chúng tôi sẽ gặp rủi ro khi viết nhiều mã hơn mức cần thiết để giải quyết vấn đề, nếu không được kiểm tra, sẽ đưa các lỗi vào ứng dụng của chúng tôi TDD thực chất là một chu kỳ gồm 3 sự kiện
Chu kỳ tiếp tục trong suốt quá trình phát triển ứng dụng và ngay cả trong quá trình bảo trì ứng dụng. Ví dụ: nếu bạn điều chỉnh một tính năng của ứng dụng, bạn bắt đầu bằng cách điều chỉnh trường hợp thử nghiệm phù hợp để phù hợp với thông số kỹ thuật mới. Điều này sẽ khiến bài kiểm tra thất bại. Sau đó, bạn tinh chỉnh mã để vượt qua bài kiểm tra và cuối cùng cấu trúc lại để đảm bảo rằng mã vẫn sạch Không cần phải nói, cần có thời gian để xây dựng thói quen này - đặc biệt là khi bạn không có thói quen kiểm tra. Tuy nhiên, người ta có thể xây dựng thói quen này bằng cách viết các trường hợp thử nghiệm và sử dụng các báo cáo về mức độ phù hợp để tinh chỉnh chất lượng mã. Trong hướng dẫn này, chúng ta sẽ sử dụng một ứng dụng có mức độ phù hợp kém ở mức tối thiểu và viết các trường hợp kiểm tra để cải thiện chất lượng mã Thiết lập Dự án DemoĐối với hướng dẫn này, chúng ta sẽ làm việc với trình mô phỏng đầu tư quỹ phòng hộ. Trong trình mô phỏng của chúng tôi, có một số chiến lược có sẵn để người dùng đầu tư vào. Người dùng cũng có một ví để gửi tiền lãi từ các khoản đầu tư. Đối với mỗi khoản đầu tư, tiền lãi được xác định dựa trên việc khoản đầu tư đó có thành công hay không. Mọi chiến lược đầu tư đều có hai số nhân - lợi tức và cứu trợ. Nếu khoản đầu tư thành công, tiền lãi của khoản đầu tư là số tiền đầu tư nhân với lợi nhuận của chiến lược. Nếu không, số tiền đầu tư sẽ được nhân với khoản trợ cấp chiến lược để nhận được tiền lãi của khoản đầu tư Hãy tiếp tục và sao chép ứng dụng
Dành vài phút để xem qua dự án và làm quen với nó. Từ nghiên cứu điển hình của dự án, chúng tôi có thể xác định bốn nguồn lực
Ngoại trừ tài nguyên 7, có sẵn một lộ trình API để tạo, cập nhật, xóa và tìm một tài nguyên. Một điểm cuối cũng được cung cấp để nhận tất cả từng tài nguyên. Bạn có thể xem các tuyến đường được hiển thị bởi API trong 1Tiếp theo, cài đặt các phụ thuộc ứng dụng bằng lệnh sau
Sau khi quá trình hoàn tất, hãy tiếp tục tạo cơ sở dữ liệu cho ứng dụng của bạn và sửa đổi tệp 2 cho phù hợp
Hoán đổi 3, 4 và 5 bằng các giá trị thích hợp cho cơ sở dữ liệu của bạnCó một lược đồ cơ sở dữ liệu hiện có và các lớp Seeder được tạo cho ứng dụng demo và nằm trong các thư mục 6 và 7 tương ứng. Đưa ra lệnh sau để cập nhật cơ sở dữ liệu đã tạo của bạn với lược đồ và thêm một số dữ liệu thử nghiệm vào đó sau đó
Phục vụ ứng dụng của bạn và thử thực hiện một số yêu cầu 6thử nghiệmĐể thử nghiệm, bạn sẽ sử dụng PHPUnit. Tất cả các bài kiểm tra của bạn sẽ được đặt trong thư mục 8 của ứng dụng. Cấu trúc thư mục chúng tôi sẽ sử dụng sẽ là cấu trúc phù hợp với cấu trúc ứng dụng. Mã để kiểm tra bộ điều khiển của bạn sẽ nằm trong thư mục 9. Tên được đặt cho các tệp kiểm tra của bạn cũng sẽ khớp với tên của lớp bạn đang kiểm tra. Ví dụ: tên của tệp chứa các trường hợp thử nghiệm cho InvestmentController của chúng tôi là 60Cuối cùng, tất cả các chức năng kiểm tra của bạn sẽ có tiền tố là 61. Ví dụ: nếu bạn muốn viết một trường hợp thử nghiệm để đảm bảo rằng Người kiểm soát đầu tư của bạn đang tạo các khoản đầu tư đúng cách, bạn có thể đặt tên hàm là 62. Tên hàm trong các trường hợp thử nghiệm của bạn phải mang tính mô tả để cho phép chúng tôi hiểu thử nghiệm nhằm mục đích đạt được điều gì. Nó cũng giúp chúng tôi quản lý mã của mình (chia thành các bài kiểm tra khác nhau nếu tên hàm quá dài)Lệnh chạy tất cả các thử nghiệm của chúng tôi được hiển thị bên dưới 2Để làm cho các thử nghiệm của chúng tôi trở nên thú vị nhanh hơn, chúng tôi sẽ sử dụng SQLite cho cơ sở dữ liệu thử nghiệm của chúng tôi. Điều này đã được cấu hình trong tệp 63. Nút 64 của bạn sẽ trông như thế này 5 65 đã được sửa đổi để khởi tạo cơ sở dữ liệu khi thiết lập các bài kiểm tra. Để tạo dữ liệu ngẫu nhiên, chúng tôi sẽ sử dụng gói Faker. Một công cụ lấy ma thuật cũng đã được thêm vào để bạn có thể dễ dàng truy cập trình giả mạo khi cần tạo dữ liệu ngẫu nhiên. 65 của bạn sẽ trông như thế này 8Mã số bảo hiểmNgoài việc chạy thử nghiệm, chúng tôi cũng muốn theo dõi phạm vi mã. Điều này cho bạn biết bao nhiêu mã bạn đã viết được bao phủ bởi các trường hợp thử nghiệm của bạn. PHPUnit cũng có thể giúp với điều đó. Để xem báo cáo về mức độ phù hợp sau khi chạy thử nghiệm, hãy thêm đối số 67. Ví dụ: để xem báo cáo phạm vi mã ngay sau khi hoàn thành kiểm tra, hãy sử dụng lệnh sau 0Đối với dự án này, bạn sẽ tạo các báo cáo của mình ở định dạng HTML bằng cách sử dụng đối số 68. Đối số này yêu cầu một thư mục để báo cáo được ghi vào. Đối với dự án của chúng tôi, đây sẽ là thư mục 69 3Để đơn giản hóa mọi thứ, một tập lệnh có tên 61 đã được thêm vào tệp 21 của dự án. Để chạy thử nghiệm và tạo báo cáo HTML, hãy nhập thông tin sau 0Điều này tạo ra một tệp HTML trong thư mục 69. Mở tệp 23 trong trình duyệt của bạn để xem báo cáo phạm vi mã của bạn
Bạn cũng có thể theo các liên kết để xem báo cáo chi tiết hơn. Ví dụ: báo cáo bảo hiểm cho thư mục 26 của bạnNhư bạn có thể thấy, không có mã nào chúng tôi đã viết được kiểm tra. Điều này có nghĩa là chúng tôi không thể dự đoán hành vi của ứng dụng của chúng tôi. Lý tưởng nhất là chúng tôi muốn mức độ bao phủ mã của mình càng gần 100% càng tốt để đảm bảo rằng mọi dòng mã chúng tôi đã viết đều được bao phủ đúng cách trong các trường hợp thử nghiệm của chúng tôi. Như bạn cũng sẽ thấy ở phần sau của hướng dẫn này, mức độ phù hợp 100% không đủ để đảm bảo rằng ứng dụng của chúng ta được kiểm tra đúng cách. Mặc dù đó là một khởi đầu tốt, nhưng chúng tôi phải chắc chắn rằng các trường hợp thử nghiệm của chúng tôi bao gồm MỌI tình huống có thể xảy ra trong ứng dụng của chúng tôi Viết các trường hợp thử nghiệm đầu tiênĐể bắt đầu, hãy viết một số bài kiểm tra cho 27. Đối với mỗi tuyến đường trong bộ điều khiển của chúng tôi, chúng tôi sẽ kiểm tra xem nó có trả về đúng mã phản hồi được trả về không. Chúng tôi cũng sẽ kiểm tra để đảm bảo rằng bộ điều khiển của chúng tôi đang trả lại dữ liệu chính xác cho từng yêu cầuTrong thư mục 8, tạo một thư mục mới có tên là 29. Tạo một tệp có tên 50 và thêm vào như sau 1Hàm này sẽ thực hiện một yêu cầu HTTP 51 tới hàm 52 của 27. Trước tiên, nó kiểm tra xem trạng thái phản hồi có tương ứng với phản hồi 54 không ( 55). Nó cũng kiểm tra xem cấu trúc của phản hồi API có khớp với cấu trúc được cung cấp trong hàm không. Bạn sử dụng 56 để cho biết rằng bạn muốn nút đó được lặp lại hoặc trốngTiếp theo, thêm một trường hợp kiểm tra để đảm bảo rằng chức năng 57 đang hoạt động bình thường. Thêm chức năng sau vào trường hợp thử nghiệm của bạn 2Tương tự như thử nghiệm đầu tiên, bạn đã tạo dữ liệu giả bằng cách sử dụng gói Faker và yêu cầu hàm 57 của 27. Bạn đảm bảo rằng mã phản hồi 80 ( 81) được trả lại và kiểm tra để đảm bảo mã này khớp với cấu trúc phản hồi dự kiến. Xác nhận cuối cùng là đảm bảo rằng người dùng tồn tại trong cơ sở dữ liệuTheo cách tương tự, bạn có thể kiểm tra chức năng 82 của mình như sau 3Đừng quên bao gồm các câu lệnh nhập ở trên cùng Lưu ý rằng lần này, chúng tôi không chỉ kiểm tra xem cấu trúc dữ liệu chính xác có được trả về hay không, mà chúng tôi còn kiểm tra để đảm bảo rằng dữ liệu được trả về cũng chính xác Hãy thêm một thử nghiệm khác cho hàm 83 của chúng ta 4Hàm này kiểm tra xem API có trả về dữ liệu nào trong phản hồi không. Nó cũng kiểm tra xem mã phản hồi có phải là mã phản hồi 84 không ( 85). Chúng tôi cũng có một xác nhận để đảm bảo rằng người dùng đã bị xóa khỏi cơ sở dữ liệuHãy viết một bài kiểm tra cho chức năng 86 của chúng tôi 5Trong thử nghiệm này, chúng tôi tạo một 6 và một 7, sau đó chúng tôi cố gắng cập nhật tên, họ và địa chỉ email của người dùng. Theo cách tương tự với các trường hợp thử nghiệm trước đây của chúng tôi, chúng tôi kiểm tra xem phản hồi 54 ( 55) có được trả về hay không và nội dung của phản hồi có đúng khôngCuối cùng, hãy viết một trường hợp thử nghiệm để đảm bảo rằng tất cả các khoản đầu tư cho người dùng được tải chính xác 6Đừng quên bao gồm các câu lệnh nhập ở trên cùng Trong chức năng này, chúng tôi tạo một 6, 8 và 9 mới. Sau đó, chúng tôi kiểm tra xem nó có được trả về không (theo cấu trúc phù hợp, với dữ liệu chính xác) khi chúng tôi đưa ra yêu cầu đối với hàm 04 của 27Chạy tất cả các bài kiểm tra của bạn 0Bạn sẽ thấy một cái gì đó tương tự như ảnh chụp màn hình bên dưới khi thử nghiệm của bạn chạy xong Chúng ta hãy xem báo cáo bảo hiểm của chúng tôi. Mở 23 trong trình duyệt của bạn và điều hướng đến chế độ xem 29 của bạn 27 của chúng tôi hiện đã phủ sóng đầy đủ. Tuy nhiên, điều này có nghĩa là mã của chúng tôi không có lỗi?Điều gì sẽ xảy ra nếu chúng tôi cố gắng có được một người dùng không tồn tại? Hãy thêm các trường hợp thử nghiệm khi chúng tôi cố gắng 82, 86 hoặc 31 một người dùng bị thiếu. Trong mỗi trường hợp, chúng tôi muốn trả về mã lỗi 32 ( 33 ) và đảm bảo rằng phản hồi của chúng tôi có mục nhập 34 8Ngoài ra, hãy thêm một trường hợp thử nghiệm để kiểm tra xem khi yêu cầu được gửi đến hàm 57 có thiếu một số dữ liệu bắt buộc hay không, mã phản hồi 36 ( 37) sẽ được trả lại cho người dùng 9Cuối cùng, hãy thêm một trường hợp thử nghiệm để đảm bảo rằng người dùng được lưu trữ luôn được tạo bằng ví trống 0Chạy thử nghiệm của bạn một lần nữa và kiểm tra kết quả Thật thú vị, ứng dụng của chúng tôi không thể xử lý bất kỳ trường hợp cạnh nào mà chúng tôi đã nghĩ ra — mặc dù ban đầu chúng tôi có phạm vi mã hóa 100% Cập nhật ứng dụng để vượt qua các bài kiểm traTrước khi cập nhật mã, hãy xem điều gì đang xảy ra. Khởi động máy chủ của bạn và sử dụng trình duyệt hoặc Postman của bạn, điều hướng đến 38. Bạn sẽ thấy rằng ứng dụng trả về phản hồi HTML khi không tìm thấy người dùng. Bạn cần ghi đè phản hồi mặc định khi không tìm thấy mô hình có ID đã chỉ địnhĐể thực hiện việc này, hãy mở tệp 39 và cập nhật hàm 00 để khớp với thông tin sau 1Điều này có nghĩa là mỗi khi ngoại lệ này xảy ra, một phản hồi JSON sẽ được trả về với một mục mô tả lỗi Chạy lại bài kiểm tra của bạn. Bạn sẽ thấy rằng việc xử lý 01 đã giải quyết được 3 trong số 5 lỗi trước đây của chúng tôiTiếp theo, hãy thử sửa mã của chúng ta để vượt qua bài kiểm tra 02. Mở tệp 03 và chuyển đến hàm 57. Bạn sẽ thấy rằng ví của người dùng được tạo với số dư là 100 thay vì 0. Những lỗi như thế này rất phổ biến trong ngành và đây là lý do tại sao chúng tôi có các thử nghiệm để đảm bảo rằng chúng tôi phát hiện ra chúng trước khi chúng được đưa vào sản xuất. Thay đổi nó thành 0 và chạy lại bài kiểm tra của bạnCuối cùng, hãy sửa mã của chúng ta để vượt qua bài kiểm tra 05. Mở tệp 03 và chuyển đến hàm 57. Chúng tôi sẽ kiểm tra xem đầu vào yêu cầu 08, 09 hoặc 10 có phải là 11 hay không và trả về phản hồi lỗi nếu có. Cập nhật chức năng 57 của bạn để phù hợp với những điều sau đây 2Chạy lại bài kiểm tra của bạn. Lần này, mã của chúng tôi vượt qua tất cả các bài kiểm tra và chúng tôi cũng có phạm vi bảo vệ mã 100% cho mẫu mã 27 và 6 của mìnhKiểm tra các điểm cuối khácSau khi hoàn thành các bài kiểm tra cho 27, hãy tiếp tục thực hiện tương tự cho các bộ điều khiển khác của chúng tôi. Trong thư mục 16, tạo một tệp mới có tên là 17. Trong 18 của bạn, hãy thêm phần sau 3 19 của chúng tôi vượt qua hầu hết các trường hợp kiểm tra ngoại trừ các bài kiểm tra 20 và 05. Để khắc phục điều đó, hãy cập nhật hàm 57 trong tệp 23 của chúng tôi 4Giống như chúng tôi đã làm trong 27, chúng tôi kiểm tra để đảm bảo rằng tất cả các trường bắt buộc đều được cung cấp trước khi cố gắng tạo một mô hình 9 mới. Chúng tôi cũng sử dụng hàm 26 để đảm bảo rằng 27 và 28 được cung cấp thực sự tương ứng với người dùng và chiến lược đã lưu trong cơ sở dữ liệu của chúng tôi. Nếu không tồn tại, một ngoại lệ 29 sẽ được đưa ra. Vì chúng tôi đã định cấu hình trình xử lý của mình để lắng nghe ngoại lệ đó, nên API của chúng tôi sẽ không thành công và trả về mã lỗi 32 ( 33) cùng với thông báo lỗiCuối cùng, chúng tôi có các bài kiểm tra cho 32 của chúng tôi. Tạo một tệp khác trong thư mục 16 có tên là 34. Trong 35 thêm vào như sau 5Với điều này, chúng tôi có phạm vi bảo hiểm 100% cho các bộ điều khiển của mình và chúng tôi cũng đã cung cấp các trường hợp cạnh để đảm bảo rằng ứng dụng của chúng tôi có thể xử lý chúng đúng cách Sự kết luậnTrong hướng dẫn này, bạn đã học cách viết các trường hợp thử nghiệm và đo lường mức độ phù hợp của mã bằng cách sử dụng 36Bạn có thể tìm thấy cơ sở mã hoàn chỉnh (với các trường hợp thử nghiệm) tại đây trên GitHub. Những cải tiến nào bạn có thể thực hiện cho ứng dụng?
Thử nghiệm là một điều cần thiết - điều mà chúng ta không thể bỏ qua nếu muốn xây dựng các ứng dụng đáng tin cậy. Chấp nhận hoàn toàn TDD đòi hỏi phải thay đổi tư duy. Thay vì tự nhủ “Tôi sẽ đi qua cây cầu đó khi đến đó”, hãy tự hỏi bản thân “Tôi dự kiến sẽ đi qua những cây cầu nào và tôi sẽ đi qua chúng như thế nào?” Olususi OluyemiKỹ sư phần mềm / Người tạo nội dung kỹ thuật Oluyemi là một người đam mê công nghệ với nền tảng về Kỹ thuật Viễn thông. Anh dấn thân vào lĩnh vực lập trình với niềm đam mê giải quyết các vấn đề hàng ngày mà người dùng gặp phải. Kể từ đó, anh ấy đã hướng các kỹ năng giải quyết vấn đề của mình vào việc xây dựng phần mềm cho cả nền tảng web và di động. Là một kỹ sư phần mềm toàn diện với niềm đam mê chia sẻ kiến thức, Oluyemi đã xuất bản nhiều bài báo và nội dung kỹ thuật trên một số blog trên toàn thế giới. Là một người am hiểu công nghệ, sở thích của anh ấy bao gồm thử các ngôn ngữ và khuôn khổ lập trình mới. PHPUnit Laravel là gì?Sử dụng Laravel Unit Testing để tránh những sai lầm làm hỏng dự án. Pardeep Kumar. 7 phút đọc. PHPUnit là một trong những gói thử nghiệm đơn vị nổi tiếng nhất và được tối ưu hóa cao của PHP . Nó là lựa chọn hàng đầu của nhiều nhà phát triển để khắc phục các lỗ hổng phát triển khác nhau của ứng dụng.
PHPUnit dùng để làm gì?PHPUnit là khung thử nghiệm đơn vị cho ngôn ngữ lập trình PHP . Nó là một ví dụ về kiến trúc xUnit cho các khung kiểm tra đơn vị có nguồn gốc từ SUnit và trở nên phổ biến với JUnit. PHPUnit được tạo bởi Sebastian Bergmann và quá trình phát triển của nó được lưu trữ trên GitHub.
Kiểm tra đơn vị trong PHP là gì?Về cơ bản, thử nghiệm đơn vị có nghĩa là bạn chia nhỏ ứng dụng của mình thành các phần đơn giản nhất và kiểm tra các phần nhỏ này để đảm bảo rằng mỗi phần không có lỗi (và an toàn). This testing is automated and written by software engineers as part of their development process.
Sự khác biệt giữa kiểm tra đơn vị và tính năng là gì?Kiểm tra tính năng và đơn vị là các phương pháp kiểm tra phần mềm cô lập một phần của hệ thống và kiểm tra nó. Một bài kiểm tra đơn vị có thể xem xét một cái gì đó nhỏ như một phương pháp duy nhất. g. thêm một hàng vào cơ sở dữ liệu, trong khi kiểm tra tính năng sẽ có chế độ xem rộng hơn, chẳng hạn như đăng ký người dùng và xác thực thông tin chi tiết của họ |