Mọi người dường như có công thức riêng để thử nghiệm phù hợp với họ. Nền của tôi giống như của bạn - nhà phát triển PHP thời gian dài không sử dụng thử nghiệm (nhưng thực hiện nhiều thử nghiệm hộp màu trắng thủ công trong khi phát triển). Gần đây, tôi đã bắt đầu viết ứng dụng cấp đầu tiên, được trả tiền-để-chơi-với-Rails của mình. Dưới đây là những suy nghĩ của tôi sau ba tháng đầu tiên.
Tôi cũng tìm thấy Dưa chuột quá phức tạp để tôi bắt đầu. Tôi đã vật lộn với nó quá lâu trước khi cuối cùng nhận ra rằng tôi đã quá xa khỏi khuôn khổ thử nghiệm thực tế. Một khi tôi vứt xuống những thứ RSpec tinh khiết trở nên rõ ràng hơn nhiều. Điều đó nói rằng, bây giờ tôi đã viết ứng dụng đầu tiên của mình với bộ thử nghiệm mạnh mẽ, tôi nghĩ rằng tôi có thể thả Cucumber vào công thức ứng dụng Rails tiếp theo của mình và cảm thấy thoải mái hơn khi sử dụng nó để thử nghiệm tích hợp trong khi vẫn sử dụng RSpec để kiểm tra đơn vị.
Tôi đã phát triển một sự say mê không lành mạnh với RSpec khi tôi cuối cùng đã hiểu quy trình. Nó thực sự là đẹp để chạy những bài kiểm tra và nhìn thấy tất cả các màu xanh lá cây. Trên thực tế, nó thậm chí còn thỏa mãn để thấy màu đỏ bởi vì nó cho tôi biết phải làm gì tiếp theo.
Tôi đang sử dụng Webrat mặc định cho các bài kiểm tra tích hợp. Tôi đã không chạy lên chống lại bất cứ điều gì mà Webrat không thể giải quyết, nhưng tôi đã không cho Capybara một thử hoặc là có lẽ tôi chỉ không biết làm thế nào xấu tôi có nó.
Tôi bắt đầu viết các bài kiểm tra bằng cách làm theo cuốn sách hướng dẫn Rails, và trong đó tác giả nói: "Vì tôi không phải là một phần để tách các bài kiểm tra cho người xem hoặc người trợ giúp , bước đầu tiên của chúng tôi là xóa chúng. " (Trang 93, đoạn 2) Sau khi viết một loạt các phương thức trợ giúp, tôi quyết định quay lại và viết các bài kiểm tra trợ giúp riêng biệt cho tất cả chúng. Tôi vẫn đang kiểm tra các bài kiểm tra của tôi trong các bài kiểm tra của mình, nhưng tôi có thể thấy việc tách chúng trong dự án tiếp theo của tôi. FWIW, tôi nghĩ bạn nên viết bài kiểm tra cho mọi thứ ở cấp độ nào đó, ngay cả khi bạn chỉ dựa vào các bài kiểm tra để thực hiện các quan điểm của bạn, và/hoặc các bài kiểm tra xem của bạn để thực hiện các phương thức trợ giúp của bạn.
Tôi đang sử dụng Factory Girl với dự án này và tôi thấy nó rất hữu ích và dễ sử dụng. Tôi đã không thử Machinist nhưng nó có vẻ là phổ biến như nhau.Một điều tôi sẽ đề cập đến là khi tôi lần đầu tiên bắt đầu viết các nhà máy của tôi, tôi cũng sử dụng đá quý FFaker để tạo ra nội dung ngẫu nhiên vào mọi đối tượng nhà máy mà tôi tạo ra. Điều này có vẻ tốt đẹp lúc đầu là nội dung biến đôi khi khiến tôi tìm thấy những thứ mà tôi đã bỏ lỡ trong quá trình phát triển (không thể nghĩ ra một ví dụ điển hình vào lúc này), nhưng nó cũng có nghĩa là tôi phải lo lắng về việc cắt xén tất cả trả về dữ liệu FFaker để phù hợp với các ràng buộc về độ dài trong mô hình. Điều này được chứng minh là quá khó sử dụng trong thời gian dài vì vậy tôi đã xóa tất cả mã đó và sử dụng các chuỗi tĩnh cho tất cả các nhà máy của tôi và chỉ cho các trường bắt buộc. Sau đó, khi tôi muốn thực hiện một lĩnh vực cụ thể, tôi sẽ làm như vậy trong thông số kỹ thuật thực tế của tôi. IMO, các nhà máy của bạn chỉ nên chứa đủ dữ liệu để tạo đối tượng hợp lệ và không còn nữa.
Đối với chế nhạo, tôi chỉ tìm thấy một vài nơi mà tôi cần để chế nhạo một cái gì đó, nhưng có lẽ tôi quá mới để Rspec biết rằng tôi đang làm sai.
Và cuối cùng, đối với các ví dụ cụ thể, chỉ cần xem GitHub ví dụ như ứng dụng Rails hoặc dự án Rails nguồn mở có chứa thử nghiệm. Hoặc làm theo cùng với cuốn sách hướng dẫn Rails như tôi đã làm. Dù bạn quyết định làm gì, hãy bắt đầu càng gần với kim loại càng tốt và sau đó thử các loại đá quý/bổ sung khác nhau, luôn đảm bảo bạn có thể lùi lại những thay đổi nếu bạn quyết định không thích kết quả. Tôi thấy rằng cố gắng để bắt đầu với một công thức hoàn chỉnh (tức là treo, ánh sáng màu xanh đặc biệt, vv) là quá áp đảo. Bằng cách bắt đầu với một ứng dụng Rails thô tôi đã có thể thử các giải pháp khác nhau (kẹp giấy so với carrierwave, typus so với rails_admin, giải phóng mặt bằng so với devise, v.v.) để xem giải pháp nào phù hợp với sở thích cá nhân của tôi. Rõ ràng là không có công thức hoàn hảo nào cho ứng dụng Rails và công thức ưa thích của mọi người chỉ là một ý kiến.