[MUSIC]
Trong bài giảng và bài tập trước đó theo sau bài giảng,
chúng tôi đã kiểm tra việc sử dụng các bài kiểm tra đơn vị trong Angular.
Chúng tôi đã thấy cách các phần khác nhau của ứng dụng Angular của chúng tôi, các thành phần,
các dịch vụ, các chỉ thị, các đường ống có thể được kiểm tra bằng cách sử dụng các bài kiểm tra đơn vị.
Nhưng tất nhiên, các
bài kiểm tra đơn vị không tiết lộ mọi thứ về sự tương tác giữa các thành phần.
Đó là nơi mà các chiến lược thử nghiệm đầu cuối cho phép chúng ta
nhìn thấy toàn bộ ứng dụng hoạt động như một đơn vị duy nhất.
Vì vậy, trong bài giảng này, chúng tôi sẽ xem xét việc sử dụng các bài kiểm tra End--to-End và
vai trò của chúng trong chiến lược thử nghiệm tổng thể cho các ứng dụng Angular của chúng tôi.
Trong bài tập sau đây, chúng ta sẽ xem xét ngắn gọn về cách chúng ta có thể tiến hành
kiểm tra đầu cuối cho ứng dụng Angular của chúng tôi, sử dụng một công cụ gọi là Protractor.
Như chúng ta đã học được trong bài giảng trước đó, các bài kiểm tra đơn vị
cung cấp cho chúng ta một cơ hội tuyệt vời để kiểm tra các đơn vị của chúng tôi trong sự cô lập.
Đảm bảo rằng các đơn vị của chúng tôi thực hiện những gì họ mong đợi sẽ thực hiện,
logic của chúng là chính xác, và tương tác giữa các thành phần và
mẫu của nó được thiết lập tốt.
Nhưng tất nhiên, các bài kiểm tra đơn vị không
hoàn thành toàn bộ bức tranh về cách một ứng dụng Angular điển hình hoạt động.
Bạn không có các đơn vị riêng lẻ làm việc trong sự cô lập.
Thay vào đó, các thành phần của bạn tương tác với các dịch vụ.
Các thành phần có thể sử dụng các loại.
Các dịch vụ, lần lượt, sẽ tương tác với phụ trợ để lấy dữ liệu.
Và sau đó bản thân thành phần sẽ chịu trách nhiệm
hiển thị các chế độ xem bằng cách sử dụng các mẫu cho thành phần.
Vậy làm thế nào để toàn bộ các đơn vị này làm việc cùng nhau?
Và làm thế nào để chúng tôi đảm bảo rằng việc làm việc cùng nhau của
các đơn vị này hoàn toàn không có vấn đề?
Vì vậy, đó là nơi kiểm tra đầu cuối và trên đường đi,
kiểm tra tích hợp giúp chúng tôi để bao gồm các loại kịch bản.
Tất nhiên, các bài kiểm tra đơn vị đóng một vai trò quan trọng trong chiến lược thử nghiệm tổng thể.
Nhưng nếu không thực hiện các bài kiểm tra đầu cuối,
chúng tôi không thể hoàn toàn chắc chắn rằng ứng dụng của chúng tôi đang hoạt động như mong đợi.
Một điều mà tôi phải nhấn mạnh là các bài kiểm tra đơn vị là nhanh chóng và
rất dễ lặp lại và có thể được thực hiện nhiều lần. Kiểm
tra tích hợp và kiểm tra đầu cuối là chậm, và vì vậy chúng
chỉ được sử dụng ít để xác nhận rằng ứng dụng của bạn đang hoạt động như mong đợi.
Vì vậy, khi chúng ta nhìn vào chiến lược thử nghiệm tổng
thể của mình, chúng ta có thể nhìn vào nó như được tổ chức dưới dạng kim tự tháp.
Ở dưới cùng của kim tự tháp, chiếm toàn bộ cơ sở và
hình thành nền tảng của chiến lược thử nghiệm tổng thể của chúng tôi, là các bài kiểm tra đơn vị.
Như chúng ta đã học được, các bài kiểm tra đơn vị cho phép chúng ta kiểm tra các đơn vị riêng lẻ một cách cô lập,
đảm bảo rằng logic của chúng và
cách các đơn vị này hoạt động là chính xác.
Và những bài kiểm tra này có thể được lặp lại rất thường xuyên.
Và thực sự, cần được lặp lại thường xuyên để đảm bảo rằng các đơn vị cá nhân
đang hoạt động như mong đợi.
Tất nhiên, ở một cấp độ thứ hai của chiến lược này sẽ là kiểm tra tích hợp.
Làm thế nào một nhóm nhỏ các đơn vị làm việc cùng nhau trong việc
thực hiện bất cứ điều gì cần thiết để được thực hiện bởi nhóm các đơn vị đó?
Vì vậy, có lẽ chúng ta có thể kiểm tra một thành phần cùng với các
dịch vụ của nó để xem dòng chảy của thông tin giữa chúng xảy ra như thế nào.
Nhưng ở trên cùng của kim tự tháp này là các thử nghiệm cuối đến cuối nơi
chúng ta nhìn vào ứng dụng tổng thể.
Và ứng dụng tổng thể đang hoạt động tốt như thế nào và
đáp ứng các yêu cầu mong đợi của nó.
Vì vậy, đó là nơi chúng ta thấy việc sử dụng các bài kiểm tra đầu cuối.
Như bạn có thể đã mong đợi bởi sơ đồ này, các bài kiểm tra đầu cuối là chậm.
Và vì vậy chúng tôi không thực hiện các bài kiểm tra đầu cuối rất thường xuyên, thay vào đó,
đơn vị kiểm tra hình thành chiến lược cốt lõi để thử nghiệm ứng dụng Angular của chúng tôi.
Các bài kiểm tra đầu cuối đóng góp trong bức tranh tổng thể, nhưng chúng được thực hiện không
thường xuyên, nhưng vẫn là một phần thiết yếu trong chiến lược thử nghiệm của chúng tôi.
Vậy làm thế nào để chúng ta thực hiện các bài kiểm tra từ cuối đến cuối?
Hãy nói ngắn gọn về các công cụ có sẵn cho chúng tôi.
Môi trường thử nghiệm Angular cho các thử
nghiệm đầu cuối được hỗ trợ bởi một công cụ có tên là Protractor.
Ai nói rằng những kẻ đam mê không có cảm giác hài hước?
Máy đo lường, góc cạnh, đây rồi.
Vậy thước đo chính xác là gì?
Protractor là, như bạn có thể mong đợi, một chương trình nút.
Vì vậy, điều này cho phép chúng tôi thực hiện các bài kiểm tra đầu cuối.
Vì vậy, Protractor chạy các bài kiểm tra đối với ứng dụng của bạn.
Vì vậy, Protractor tải ứng dụng của bạn vào một trình duyệt và tương tác với
các ứng dụng giống như một người dùng thực sự sẽ tương tác với ứng dụng của bạn.
Vì vậy, chúng tôi đang xem xét tương tác với ứng dụng của bạn,
mặc dù lập trình, nhưng thực hiện các loại hoạt động mà
một người dùng điển hình sẽ thực hiện như nhấp vào liên kết, điền vào các biểu mẫu.
Gửi biểu mẫu, điều hướng đến các phần khác nhau của ứng dụng của bạn và vân vân.
Vì vậy, đây là nơi Protractor tận dụng việc sử dụng một WebDriver để kiểm soát các
trình duyệt mà trên đó các thử nghiệm có thể được thực hiện.
Một ứng dụng framework như vậy được gọi là Selenium Framework,
được sử dụng để thực hiện kiểm tra tự động trong trình duyệt.
Nếu bạn đang sử dụng Chrome như một phần của chiến lược thử nghiệm hoặc Firefox,
thì bạn có thể sử dụng những gì được gọi là kết nối trực tiếp.
Điều đó có sẵn thông qua một Protractor để kết nối trực tiếp với các trình duyệt này và
thực hiện kiểm tra trong các trình duyệt đó.
Bây giờ, các bài kiểm tra tự tận dụng khuôn khổ điều chỉnh để
thể hiện bài kiểm tra.
Vì vậy, bạn vẫn sẽ thấy người dùng mô tả một int và
trước mỗi mà bạn đã nhìn thấy với các bài kiểm tra đơn vị.
Ngoại trừ rằng bây giờ, chúng tôi sẽ được tận dụng sự hỗ trợ thước đo
để có thể tạo ra tương tác giống như người dùng thực sự với
ứng dụng của chúng tôi bằng cách sử dụng mã.
Vì vậy, đó là những gì chúng ta sẽ học trong bài tập mà sau bài
giảng đặc biệt này.
Chúng tôi sẽ sử dụng Protractor và viết các chiến lược thử nghiệm đầu cuối của chúng tôi.
Và tất nhiên, tận dụng hỗ trợ Angular CLI để
thực hiện các bài kiểm tra đầu cuối trong bài tập sau bài giảng này.
[ NHẠC]