Computer >> Máy Tính >  >> Lập trình >> Ruby

Bắt đầu với kiểm tra hệ thống trong Rails với Minitest

Trong bài đăng hôm nay, chúng ta sẽ xem xét các bài kiểm tra hệ thống trong Rails 6. Kiểm tra hệ thống có nghĩa là tự động kiểm tra cách người dùng tương tác với ứng dụng của bạn, bao gồm cả Javascript trong giao diện người dùng của bạn. Minitest, là khung thử nghiệm mặc định trong Rails, là một kết hợp tuyệt vời để thử nghiệm hệ thống. Với tất cả cấu hình mà Rails xử lý cho chúng tôi, chỉ cần một vài bước trước khi chúng tôi bắt đầu và chạy thử nghiệm đầu tiên của mình.

Kiểm tra hệ thống đã được thêm vào ngăn xếp Rails trong Rails 5.1. Khi tôi bắt đầu sử dụng chúng, tôi cảm thấy khó thu thập thông tin cập nhật, có liên quan không phải về RSpec. Đây là tất cả những gì mới nhất và hay nhất mà tôi đã thu thập được khi làm việc với các bài kiểm tra hệ thống với Minitest.

Giới thiệu về Kiểm tra Hệ thống

Trong thuật ngữ Rails, kiểm thử hệ thống đề cập đến việc "kiểm tra một ứng dụng như một hệ thống toàn bộ". Điều đó được thực hiện bằng cách sử dụng trình duyệt trong các thử nghiệm. Thay vì kiểm tra các phần riêng biệt, với các bài kiểm tra hệ thống, chúng tôi có thể kiểm tra toàn bộ 'quy trình làm việc', giống như những gì người dùng trải qua khi tương tác với ứng dụng của chúng tôi, bao gồm cả các phần JavaScript. Trong thực tế, điều đó có nghĩa là chúng tôi không muốn kiểm tra hệ thống để kiểm tra nếu một bản ghi được tạo trong cơ sở dữ liệu khi người dùng nhấp vào một nút; chúng tôi chỉ kiểm tra xem bản ghi mới đó có xuất hiện trên màn hình của họ hay không. Các loại kiểm tra tương tác người dùng này còn được gọi là kiểm tra tính năng hoặc kiểm tra chấp nhận. Chúng khác với các bài kiểm tra tích hợp:các bài kiểm tra tích hợp là để kiểm tra hành vi, đặc biệt là của tất cả các phần của ứng dụng cùng nhau, nhưng không qua giao diện người dùng.

Cấu hình

Cấu hình quá đơn giản, nó gần như khó hiểu.

Đá quý Capybara được sử dụng để tương tác với trình duyệt. Thông qua Capybara, chúng tôi có thể thực hiện các bài kiểm tra truy cập các trang, điền vào biểu mẫu, nhấp vào các liên kết và nút. Nếu bạn đã làm việc với Capybara trước đây, bạn biết tất cả những thứ bạn phải phối hợp để làm cho nó hoạt động với chiến lược dọn dẹp cơ sở dữ liệu và cấu hình trình duyệt. Hoan hô cho quá trình thiết lập kiểm tra hệ thống Rails:nó xử lý tất cả cấu hình cần thiết để hoạt động với Capybara out-of-the-box. Vì vậy, chúng tôi có thể tập trung vào bài kiểm tra viết thực tế. Nó sử dụng trình điều khiển Selenium theo mặc định.

Từ tài liệu:“Theo mặc định, ActionDispatch ::SystemTestCase được điều khiển bởi trình điều khiển Selenium, với trình duyệt Chrome và kích thước trình duyệt là 1400x1400.” Trình điều khiển Selenium khác với trình điều khiển mặc định của Capybara và được chọn vì nó hoạt động với Javascript.

Tất cả các cài đặt có sẵn thông qua application_system_test_case.rb . Điều duy nhất bạn cần làm là yêu cầu điều này trong mỗi tệp thử nghiệm. 

#application_system_test_case.rb (default)
 
 
require "test_helper"
 
class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :chrome, screen_size: [1400, 1400]
end

Nếu bạn đã tạo một ứng dụng mới với Rails 6, đây thực sự là tất cả những gì bạn cần. Có nghĩa là:bạn có thể bỏ qua tất cả các lời khuyên về cách thiết lập trình điều khiển Selenium mà Internet hiển thị để kiểm tra giao diện người dùng hoặc kiểm tra tính năng của RSpec.

Trong các ứng dụng hiện có, việc tạo khung sẽ tự động tạo application_system_test_case.rb và mọi thứ bạn cần để kiểm tra hệ thống.

Khi Eileen Uchitelle giới thiệu các thử nghiệm hệ thống, Chrome đã được chọn thay vì Firefox vì lúc đó FF không chơi tốt với Selenium. Điều đó đã được khắc phục trong các phiên bản Firefox sau này. Vì vậy, tôi thay thế Chrome bằng FF, như sau:

#application_system_test_case.rb (change driver to Firefox)
 
require "test_helper"
 
class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :firefox, screen_size: [1400, 1400]
end

(Ban đầu, tôi chạy $ rails db:test:prepare after chuyển đổi trình điều khiển để đảm bảo khởi động sạch sẽ, NHƯNG trình chạy thử nghiệm mới cũng quan tâm đến điều đó:gọi thử nghiệm sẽ tự động chạy :prepare. )

Mới trong Rails 6

Kể từ khi giới thiệu các thử nghiệm hệ thống trong 5.1, đá quý trợ giúp trình khắc phục sự cố đã không còn được dùng nữa. Trong các ứng dụng Rails 6 mới, nó được thay thế bằng đá quý webdrivers. Trong ứng dụng Rails 5, bạn nên thay thế chromedriver-helper bằng webdrivers gem nếu bạn chưa làm điều đó. Với đá quý webdrivers tại chỗ, bạn thậm chí không cần đá quý selen-webdriver; webdrivers cũng quan tâm đến điều đó. Thực tế thú vị:Rails 6 cung cấp cho chúng ta cả gem selenium-webdriver và webdrivers gem.

Kiểm tra tình trạng:Những gì bạn không cần thêm

Thiết lập Capybara từng là một nỗi đau. Không rõ bạn cần những gì để thiết lập nó từ đầu, bao gồm việc tìm chiến lược dọn dẹp cơ sở dữ liệu chính xác, các yếu tố phụ thuộc của đá quý capybara-webkit và tất cả các loại yêu cầu bất ngờ mà bạn cần tìm ra trước khi có thể bắt đầu viết thử nghiệm. Bây giờ Rails cung cấp mọi thứ chúng ta cần, tôi thấy phần khó hiểu duy nhất là tất cả thông tin có sẵn trong hướng dẫn và tài liệu hiện đã lỗi thời. Đây là một số điều mà chúng ta có thể bỏ qua bây giờ.

Đầu tiên, thiết lập Rails nấu sẵn có nghĩa là chúng ta có thể bỏ qua nhiều đá quý hơn thường được đề cập đến liên quan đến thử nghiệm, như minitest-rails-capybara hoặc các tính năng bổ sung cho Minitest:đầu ra giống màu, kiểm tra lỗi nhanh và chạy một dòng / kiểm tra. Các tính năng Minitest này có trong trình chạy thử nghiệm được giới thiệu trong Rails 5.0.

Không cần đến gem database_cleaner nữa; Rails thực hiện việc dọn dẹp cho chúng tôi ('kiểm tra giao dịch').

Vì Rails sử dụng Selenium thay vì Capybara mặc định, chúng tôi không cần capybara-webkit và chúng tôi không cần thực hiện bất kỳ thao tác bổ sung nào để bao gồm kiểm tra các phần tử Javascript.

Bạn thậm chí không cần sử dụng save_and_open_screenshot của Capybara , bởi vì Rails cung cấp một take_screenshot phương pháp. Nó lưu ảnh chụp màn hình trong /tmp và cung cấp một liên kết trong đầu ra thử nghiệm để dễ dàng truy cập.

Lựa chọn giữa trình duyệt thực và trình duyệt không có đầu

Tôi không thể xem đủ các bài kiểm tra hệ thống đang chạy trong trình duyệt và xem tất cả các liên kết được nhấp như thế nào, các biểu mẫu được điền vào, v.v. Nhưng, nó chậm. Để tăng tốc độ chạy thử nghiệm, bạn có thể sử dụng trình duyệt 'không có đầu':đó là trình duyệt có cùng quyền truy cập vào ứng dụng của bạn như một trình duyệt thông thường, nhưng không có giao diện người dùng đồ họa. Có nghĩa là:nó hoạt động giống nhau nhưng bạn không thực sự thấy các thử nghiệm thực hiện công việc của chúng vì trình điều khiển không đầu không mở cửa sổ trình duyệt thực tế.

Nếu bạn muốn không có đầu, có headless_chrome và headless_firefox . Để sử dụng chúng, cần có một thay đổi nhỏ:

# To change driver to headless_*
#application_system_test_case.rb (change driver to headless_*:)
 
require "test_helper"
 
class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :headless_firefox
end

Lưu ý:Trong tài liệu Rails và trong một số bài báo tôi tìm thấy, Poltergeist được đặt tên là một tùy chọn cho trình điều khiển. Nó từng phổ biến như là trình điều khiển PhantomJS không đầu cho Capybara. PhantomJS đã bị bỏ rơi. Vì vậy, không cần phải đi sâu vào chi tiết — lý do tôi đề cập đến nó ở đây là vì Poltergeist và PhantomJS vẫn được đề cập trong tài liệu Rails.

Bạn có thể làm nhiều tùy chỉnh hơn, nhưng để bắt đầu, đây thực sự là tất cả những gì bạn cần.

Chạy thử nghiệm

$ rails test sẽ chạy tất cả các bài kiểm tra ngoại trừ các bài kiểm tra hệ thống. Bạn cần chạy $ rails test:system một cách rõ ràng . (Sự thật thú vị:$ rails lệnh sẽ luôn chạy qua bin / rails. Không cần nhập $ bin/rails nữa.)

  • Chạy tất cả các bài kiểm tra hệ thống:$ rails test:system
  • Chạy thử nghiệm trong một tệp cụ thể (tại đây:users_test.rb) $ rails test/system/users_test
  • ... hoặc một thử nghiệm cụ thể:$ rails test test/system/users_test.rb:21
  • Để chạy tất cả các bài kiểm tra:trước tiên hãy chạy các bài kiểm tra hệ thống:$ rails test:system test

Lưu ý:các cờ tùy chọn không hoạt động với test:system; nếu bạn muốn sử dụng các cờ như -f (đối với lỗi nhanh) hoặc -v (để biết chi tiết), hãy sử dụng $ rails test test/system -v -f

Điều gì (Không) để Kiểm tra

Các bài kiểm tra hệ thống bổ sung cho các bài kiểm tra đơn vị, không thay thế. Nó sẽ làm để kiểm tra một đường dẫn hạnh phúc, cộng với một đường dẫn có thể có thông báo lỗi hoặc chuyển hướng. Kiểm tra hệ thống không có nghĩa là để kiểm tra tất cả các trường hợp cạnh trong trình duyệt; chỉ bao gồm các tính năng chính.

Khi chọn đối tượng kiểm tra của mình, tôi cố gắng tìm một thực thể để kiểm tra phản ánh cách người dùng sử dụng ứng dụng. Để đặt tên cho các bài kiểm tra của mình, tôi đã mượn quy ước đặt tên ROLE_ACTION_test.rb của GitLab, phù hợp với cách tiếp cận này. Ví dụ:user_shares_card_test.rb .

Mẹo và thủ thuật chung

  • Nếu bạn sử dụng Devise để xác thực, bạn có thể sử dụng trình trợ giúp tích hợp Devise để đăng nhập và đăng xuất người dùng thử nghiệm. Thêm include Devise::Test::IntegrationHelpers vào một lớp kiểm tra hoặc thêm nó vào test_helper.rb để làm cho chúng có sẵn trong tất cả các thử nghiệm. Giờ đây, bạn có thể tạo người dùng và sign_in(@user) . Nếu bạn đặt nó trong một setup , bạn không cần phải đăng xuất người dùng trong một lần chia nhỏ. Rails đảm nhận việc dọn dẹp những gì trong phương pháp thiết lập.
  • Làm việc với các biểu mẫu, thật hấp dẫn khi tham chiếu các id mà Rails tạo tự động từ tên mô hình + tên trường và các loại nút cho click_on S. (fill_in "user_email" , click_on :commit ). Nhưng vì các bài kiểm tra hệ thống là về những gì người dùng thực sự sẽ thấy trên màn hình của họ, thật hợp lý khi sử dụng các phần tử hiển thị, tức là văn bản. Một lựa chọn hợp lý sẽ là có các khóa tham chiếu trong các tệp ngôn ngữ i18n và sử dụng các khóa đó thay vì các văn bản chữ luôn thay đổi. (fill_in :user_email ). Capybara chỉ tìm thấy văn bản với cú pháp I18n đầy đủ:assert_selector "h1", text: I18n.t("activerecord.models.things") .
  • Trình trợ giúp đường dẫn được bao gồm theo mặc định. Đối với một số thư viện, bạn cần bao gồm trình trợ giúp trong lớp thử nghiệm, ví dụ:include ActionMailer::TestHelper , để sử dụng assert_emails phương pháp.
  • Tạo các lớp tùy chỉnh để chạy thử nghiệm trên các kích thước màn hình khác nhau. Xem hướng dẫn.
  • Tính năng chụp màn hình cũng có thể được sử dụng để chụp ảnh màn hình cho tài liệu và tài liệu quảng cáo của bạn. Nếu bạn đặt nó thành video truyền hình màn hình và làm chậm tốc độ phát lại, bạn sẽ có video sản phẩm trong vài phút!
  • Rails cung cấp một trình tạo cho các bài kiểm tra hệ thống.
  • Minitest trong Rails hơi khác so với bản thân Minitest và cũng bổ sung thêm các phương thức và xác nhận cụ thể của Rails. Trước tiên hãy kiểm tra tài liệu Rails trước tài liệu Minitest.

Tôi cảm thấy rất vui với các bài kiểm tra hệ thống và phần lớn là nhờ việc sử dụng nó dễ dàng như thế nào.

Kết luận

Trong bài đăng này, chúng tôi đã xem xét cấu hình mà Rails cung cấp và những tùy chỉnh tối thiểu nào mà chúng tôi có thể muốn thêm vào. Minitest rất tuyệt để viết các bài kiểm tra Hệ thống. Một số mẹo và thủ thuật sẽ giúp bắt đầu và chạy các thử nghiệm hệ thống đầu tiên của bạn. Xem họ làm điều kỳ diệu của họ trong trình duyệt!