Hãy để tôi nói ngắn gọn với các bạn về thử nghiệm góc cạnh.
Làm thế nào để bạn thiết kế các ứng dụng góc cạnh của bạn để được kiểm tra?
Làm thế nào để bạn thiết kế các bài kiểm tra cho ứng dụng góc cạnh của bạn?
Làm thế nào để bạn thực hiện các bài kiểm tra và đảm bảo rằng
ứng dụng góc cạnh của bạn đáp ứng tất cả các bài kiểm tra mà bạn đã
viết ngay cả khi bạn đang phát triển ứng dụng góc cạnh của bạn?
Bây giờ đây là nơi tôi cũng sẽ nói ngắn gọn về
sự phát triển theo hướng thử nghiệm của các ứng dụng góc cạnh.
Thật thú vị, góc cạnh chính nó đã được xây dựng từ mặt đất lên để cho phép thử nghiệm,
là một phần của sự phát triển ứng dụng góc cạnh của bạn.
Lực lượng chính đằng sau góc Misko Hovery là một kỹ sư thử nghiệm của Google và do đó,
ảnh hưởng của ông đối với việc thiết kế góc cạnh để được kiểm tra từ
mặt đất lên có thể dễ dàng được nhìn thấy trên tất cả các khuôn khổ.
Vì vậy, góc cạnh chính nó như bạn đã hiểu từ các bài giảng và bài tập trước đó,
là mô đun trong tự nhiên.
Vì vậy, các mô-đun của góc cạnh cùng với các thành phần và các
mẫu của chúng và sau đó là các dịch vụ và các đường ống và các chỉ thị,
có nghĩa là góc cạnh cho chính nó dễ dàng để được thử nghiệm.
Bây giờ, bởi vì các ứng dụng góc cạnh chính nó được cấu tạo bởi các phần khác nhau,
bạn có thể kiểm tra từng phần trong số đó một cách cô lập đầu tiên
ngay cả trước khi chúng trở thành một phần của toàn bộ ứng dụng góc cạnh.
Khía cạnh thứ hai là cơ chế tiêm phụ thuộc đòn bẩy góc
để hỗ trợ sự kết hợp của các phần khác nhau của
ứng dụng góc của bạn có nghĩa là bạn có thể dễ dàng thay thế mocks
cho những phụ thuộc trong
các phần khác nhau của ứng dụng góc cạnh và thực hiện các bài kiểm tra.
Tôi đã sử dụng từ giả trong,
trong câu trước sẽ đến để hiểu
rằng trong một chi tiết hơn một chút và nhiều hơn nữa rằng, slide sau.
Đây là nơi chúng ta cần phải nhận thức được
một cách tiếp cận để thực hiện phát triển ứng dụng được gọi là thử nghiệm hướng phát triển.
Trong thử nghiệm hướng phát triển, như bạn có thể hiểu bằng tên chính nó, có
nghĩa là trước tiên bạn viết các bài kiểm tra tự động cho
tất cả các chức năng mà bạn mong muốn thực hiện trong ứng dụng của bạn.
Vì vậy, đầu tiên đến bài kiểm tra,
sau đó bạn viết mã ứng dụng của bạn để vượt qua bài kiểm tra.
Vì vậy, các thử nghiệm chính nó xác định những chức năng bạn muốn thực hiện.
Sau đó bạn viết mã để thực hiện chức năng đó.
Vì bạn đã có bài kiểm tra tại chỗ,
bạn có thể kiểm tra xem liệu việc thực hiện mà bạn thực hiện có thỏa mãn bài kiểm tra hay không.
Bây giờ, tất nhiên, một khi nhận thức của bạn về chức năng của bạn thỏa mãn kiểm tra,
bạn luôn có thể cấu trúc lại mã để tuân thủ các tiêu chuẩn kỹ thuật phần mềm của họ.
Nhưng ngay cả sau đó,
bạn có thể kiểm tra lại mã để đảm bảo rằng nó vẫn đáp ứng
những yêu cầu được chỉ định trong
đó thử nghiệm cụ thể mà bạn sử dụng trong sự phát triển thử nghiệm hướng của bạn.
Vì vậy, thực sự, thử nghiệm hướng phát triển là
một cách tiếp cận rất khả thi để thiết kế
ứng dụng tốt từ mặt đất để được kiểm tra đầy đủ.
Bây giờ khi chúng ta nói về thử nghiệm,
bạn có thể tiếp cận thử nghiệm từ nhiều khía cạnh khác nhau.
Đầu tiên và quan trọng nhất là nếu ứng dụng của bạn
chính nó được thực hiện như các phần khác nhau,
như các thành phần, như các dịch vụ, như các chỉ thị,
như các đường ống mà bạn đang thực hiện trong ứng dụng của bạn.
Điều đó có nghĩa là bạn có thể dễ dàng kiểm tra từng đơn vị riêng lẻ này một cách cô lập.
Vì vậy, đó là nơi mà các bài kiểm tra đơn vị đi đầu.
Kiểm tra đơn vị có nghĩa là bạn đang kiểm tra các đơn vị riêng lẻ của mã,
đảm bảo rằng đơn vị riêng lẻ cụ thể
thỏa mãn các chức năng mà nó được cho là hỗ trợ,
và rằng chức năng và logic trong đoạn mã đó được thực hiện một cách chính xác.
Bây giờ cô lập các đơn vị và thử nghiệm nó là rất,
rất hữu ích để tìm ra hầu hết các vấn đề ban đầu trong của bạn,
trong mã của bạn và sau đó sửa chữa chúng ngay cả trước khi bạn tích hợp vá đó vào mã.
Bây giờ một khi bạn bắt đầu tích hợp các phần này vào toàn bộ,
nó trở nên cồng kềnh hơn để có thể thực hiện các bài kiểm tra chi tiết của mã của bạn.
Vì vậy, do đó, các bài kiểm tra đơn vị bị cô lập tạo thành dòng đầu tiên
của bảo vệ chống lại lỗi khi bạn đang phát triển ứng dụng của bạn,
đặc biệt là ứng dụng góc cạnh của bạn.
Bây giờ như chúng ta thấy với một góc cạnh,
chúng ta có một sự tách biệt rõ ràng giữa các thành phần góc cạnh và chính DOM.
Vì vậy, trong một thành phần, ví dụ, ở đó,
logic của thành phần của bạn được thực hiện hoàn toàn
trong mã typescript mà bạn thực hiện trong một thành phần mà các tập tin typescript.
Và sau đó bản thân DOM được điều khiển
thông qua mẫu mà bạn đã thiết kế cho thành phần góc cạnh của bạn.
Vì vậy, bản thân Beta, bạn thấy sự tách biệt rõ ràng giữa hai người.
Vì vậy, bạn có thể chỉ đơn giản là kiểm tra logic
của mã thành phần của mình mà không cần viết một mẫu dọc.
Nhưng sau đó bạn cũng có thể xem xét cả hai với nhau và sau đó đánh giá những khía cạnh đó.
Như chúng ta sẽ thấy trong bài tập sau bài giảng này,
chúng ta sẽ thực sự làm cả hai cách tiếp cận này.
Không chỉ vậy, thực tế là góc sử dụng
phụ thuộc tiêm có nghĩa là bạn có thể tiêm các phụ thuộc giả trong ứng dụng của bạn.
Khi tôi nói giả mạo, tôi có nghĩa là, ví dụ,
nếu thành phần của bạn phụ thuộc vào một dịch vụ cụ thể, bạn luôn có thể thực hiện
một dịch vụ giả mạo bắt chước hành vi của dịch vụ
và sau đó thay thế vào vị trí trong khi bạn đang thử nghiệm các thành phần để bạn có thể giữ cho
thành phần của bạn độc lập làm thế nào các dịch vụ thực sự được thực hiện.
Miễn là giao diện giữa thành phần của bạn và dịch vụ được thiết kế đúng cách,
bạn có thể thay thế một dịch vụ giả tại chỗ và vẫn kiểm tra thành phần của bạn.
Ở đó, từ mô phỏng,
bạn có thể dễ dàng kiểm soát những gì được cung cấp cho các thành phần từ dịch vụ.
Vì vậy, cách tiếp cận này cho phép bạn thực hiện kiểm tra đơn vị một cách
chi tiết trong ứng dụng góc cạnh của bạn.
Đây là nơi mà sự sẵn có của thử nghiệm khuôn khổ như “Jasmine”.
Vì vậy, những gì Jasmine cung cấp là
một khuôn khổ thử nghiệm dựa trên hành vi được thiết kế hoàn toàn trong JavaScript.
Bây giờ, khuôn khổ Jasmine này là một khuôn khổ tổng quát
có sẵn để thử nghiệm bất kỳ ứng dụng JavaScript nào.
Angular áp dụng Jasmine như là cách tiếp cận để xác định các bài kiểm tra của chúng tôi cho các bộ phận góc cạnh khác, các
thành phần của chúng, các dịch vụ và các khía cạnh khác nhau của ứng dụng góc cạnh của chúng tôi.
Bây giờ, bên trong Jasmine, Jasmine sử dụng hai thứ giúp đỡ của bạn.
Một là việc sử dụng một hàm “mô tả”.
Hàm “mô tả” cho phép bạn nhóm một tập hợp các phép thử và sau đó
thực hiện các phép thử này với nhau như một nhóm các phép thử duy nhất.
Khi chúng ta viết mã trong bài tập, bạn sẽ thấy tôi
kèm theo một tập hợp các bài kiểm tra bên trong một hàm mô tả.
Sau đó, chúng tôi viết mã của chúng tôi cho chúng tôi,
mã Jasmine, cho các bài kiểm tra góc cạnh của chúng tôi.
Bây giờ trong các chức năng “mô tả” này, bạn cũng sẽ sử dụng những gì được gọi là “nó” chức năng.
Các chức năng “nó” cho phép bạn xác định
các bài kiểm tra riêng lẻ mà bạn muốn thực hiện trên ứng dụng góc cạnh của bạn.
Vì vậy, đó là nơi bạn sẽ thấy tôi chỉ định “nó” và sau đó xác định rằng
bản chất của các thử nghiệm cụ thể và sau đó
thiết kế mã cho rằng thử nghiệm cụ thể với một trong “nó” chức năng.
Vì vậy, khi chúng tôi thiết kế các mã trong bài tập tìm ra cho “mô tả” và
“nó” trong các ứng dụng thử nghiệm góc cạnh của bạn.
Một khi bạn đã thiết kế thử nghiệm với khuôn khổ Jasmine,
Karma là một công cụ dòng lệnh dựa trên JavaScript
cho phép bạn thực hiện các thử nghiệm này một cách tự động.
Bây giờ, Karma cùng với Jasmine, cho
phép bạn thực hiện các bài kiểm tra cho ứng dụng góc cạnh của bạn.
Bây giờ với Karma, những gì Karma hỗ trợ,
là nó cho phép bạn đẻ ra
một máy chủ web trong đó bạn tải mã nguồn ứng dụng của bạn và
sau đó Karma sử dụng một trình duyệt để thực hiện các thử nghiệm thực tế của các đơn vị khác nhau của bạn.
Vì vậy, đây là nơi khi bạn chạy thử nghiệm bằng Karma,
bạn sẽ thấy Karma xếp chồng lên một trình duyệt, cho
dù đó là một cửa sổ trình duyệt của một trình duyệt hiện có
hay bạn sẽ sử dụng một cái gì đó gọi là PhantomJS mà bắt đầu
một trình duyệt ảo đằng sau hậu trường để thực hiện thử nghiệm.
Nó không quan trọng, nhưng Karma sử dụng
trình duyệt trong một khoảnh khắc để thực hiện các thử nghiệm cho ứng dụng góc cạnh của bạn.
Như bạn sẽ thấy trong bài tập sau,
đây là nơi nếu một trong các đồng nghiệp của bạn tiếp tục nhấn mạnh rằng việc thực hiện
một phần cụ thể của ứng dụng góc cạnh của bạn là
chính xác và tiếp tục nhấn mạnh điểm,
bạn luôn có thể thiết kế một vài bài kiểm tra bằng cách sử dụng Jasmine và
Karma và sau đó thực hiện các bài kiểm tra và nếu các bài kiểm tra thất bại,
bạn luôn có thể bác bỏ lập luận của họ.
Vì vậy, đó là khi bạn có thể quay
lại, quay lại với đồng nghiệp của bạn và nói,
Karma của tôi đã vượt qua giáo điều của bạn.
Bây giờ, tất nhiên, các ứng dụng góc cạnh
của bạn không hoàn toàn không có sự tham gia của khuôn khổ góc cạnh chính nó.
Thành phần của bạn không thể được thiết kế bởi chính bạn mà không
sử dụng nhiều chức năng thư viện góc cung cấp cho bạn,
mặc dù một số logic cơ bản có thể được kiểm tra độc lập với góc cạnh.
Cái mà chúng ta gọi là các bài kiểm tra bị cô lập.
Nhưng, ngày càng nhiều,
bạn sẽ thấy rằng trừ khi bạn ở,
muốn khung góc hỗ trợ bản thân bạn
sẽ không thể thực hiện nhiều thử nghiệm của các
bộ phận góc cạnh của bạn cho dù đó là các thành phần hoặc dịch vụ hoặc đường ống hoặc chỉ thị.
Vì vậy, đây là nơi mà các tiện ích thử nghiệm góc cung cấp
một môi trường thử nghiệm cho phép bạn thực
hiện các bài kiểm tra đơn vị trong ứng dụng góc cạnh của bạn.
Vì vậy, các tiện ích thử nghiệm góc cạnh như bạn sẽ thấy tôi sử dụng trong các bài tập,
trong bài tập tiếp theo,
sẽ cung cấp cho chúng tôi một số triển khai chức năng góc cạnh mà bạn sử dụng
trong các bài kiểm tra của bạn để thiết lập môi trường nơi bạn có thể thực hiện các bài kiểm tra của họ.
Vì vậy, đây là nơi mà sự tương tác với môi trường góc cạnh,
thay vì sử dụng các triển khai góc thực,
bạn sẽ sử dụng các tiện ích thử nghiệm này sẽ cung cấp
đủ chức năng để cho phép bạn thực hiện các bài kiểm tra.
Và đây là nơi mà TestBed mà chúng tôi sẽ
sử dụng trong ứng dụng góc cạnh của chúng tôi là rất, rất hữu ích.
TestBed về cơ bản tạo ra một mô-đun thử nghiệm góc cạnh.
Như bạn nhận ra, các thành phần của bạn không tồn tại một mình.
Các thành phần của bạn phải được bao gồm trong một mô-đun NG.
Bây giờ bạn không thể chỉ đơn giản là sử dụng một mô-đun NG tiêu chuẩn để thực hiện thử nghiệm của bạn.
Vì vậy, đó là nơi mà TestBed,
được hỗ trợ bởi tiện ích kiểm tra góc,
cung cấp cho bạn một môi trường mô-đun NG cho phép bạn kiểm tra các thành phần của họ.
Vì vậy, trong TestBed,
bạn sẽ sử dụng một cái gì đó gọi là TestBed Create Component để tạo ra
một thành phần cá nhân và một thể hiện của các thành phần để thực hiện các thử nghiệm trên đó.
Và khi bạn làm điều đó
TestBed cung cấp cho bạn truy cập vào một cái gì đó được gọi là ComponentFixture,
ComponentFixture là một cái gì đó cung cấp cho bạn một xử lý cho phép bạn bao quanh
thành phần của bạn với đủ chức năng để các thành phần có thể được kiểm tra bởi chính nó.
Các fixture cung cấp quyền truy cập vào các thành phần chính nó và
sau đó cũng thông qua đó chúng tôi sẽ sử dụng một cái gì đó gọi là DebugElement.
Bạn sẽ thấy tôi sử dụng điều đó trong bài tập sau.
DebugElement cung cấp cho bạn truy cập vào DOM,
đó là mẫu được hỗ trợ như là một phần của thành phần của bạn.
Vì vậy, do đó, bạn có thể thực hiện thao tác trên DOM như nhấp vào các phần tử trong DOM,
nhận được quyền truy cập vào một phần tử DOM và sau đó đọc ra
những gì được bao bọc bên trong các phần tử Dom và như vậy sẽ cho phép bạn thực hiện các bài kiểm tra.
Bây giờ, trước khi chúng ta tiếp tục tập luyện,
tôi muốn bạn nhận thức được một số trong những điều này để khi chúng ta gặp chúng
trong bài tập, bạn sẽ thấy tại sao tôi sử dụng từng phần khác nhau này.