Tôi đã test một Rails Application như thế nào? (Introduction)

Introduction

Đối với một Developer việc kiểm thử (Testing) trong một project là điều gần như là bắt buộc để có được một sản phẩm chất lượng, và đặc biệt trong một project Rails sử dụng Agile. Với Rails thì việc self-review, hay sử dụng sử các phương pháp Unit Test cực kỳ quan trọng để đảm bảo việc vận hành lẫn performance của hệ thống. Ngoài ra, với Agile nói chung hay Scrum nói riêng thì việc các Developer phải self-review, hay review chéo lẫn nhau trong team rất quan trọng, nên kỹ năng test với một Developer là một điều cần thiết để tăng chất lượng sản phẩm và tăng khả năng của bản thân.

Developer có cần thiết phải biết test không?

Ban đầu, việc phải sử dụng Testing đối với Developer với mình không hề quan trọng trong thời gian đầu tiên khi tiếp cận với Rails, hay với các project đầu tiên của bản thân, vì đơn giản theo quan điểm của mình là QA có thể xử lý được các vấn đề đó, bản thân không hiểu tại sao phải sử dụng Unit Test hay các phương pháp test trong thời gian develop, Developer chỉ cần coding và chỉ cần review sản phẩm cuả mình chạy có được không?, đúng Specification của khách hàng để ra hay không? và phần còn lại có thể để QA xử lý. Tuy nhiên, suy nghĩ của mình đã thay đổi rất nhiều khi tham gia vào một project Rails và hiểu được lý do tại sao Testing là một kỹ năng rất cần thiết không kém gì Coding đối với một Developer. Một Developer cần phải có kỹ năng test để kiểm thử sản phẩm của mình, đơn giản như đứa con mình "sinh" ra thì mình là người hiểu nó nhất thì mình phải chăm sóc nó kiểm tra nó xem nó có thực sự tốt không trước khi đưa cho QA hay đưa cho khách hàng sử dụng.

Ban đầu khi tham gia dự án, việc viết test case hay sử dụng gem test như Capybara, Rspec với mình là thứ gì đó khá tốn thời gian và vô dụng, vì đôi khi thời gian viết Test Script còn lâu hơn việc Coding. Tuy nhiên, theo thời gian khi dự án ngày càng lớn lên dần thì việc không Unit Test đã dẫn đến những hậu quả khôn lường sau này. Bạn hãy thử tưởng tượng đơn giản rằng, khi bạn viết hoàn thành 1 task thì chính bản thân là người mình là người hiểu task đó, hiểu được những ngóc ngách của từng dòng code và các case có thể gặp phải với task đó. Khác với QA họ dựa trên spec của khách hàng để nghĩ ra test case và đảm bảo yêu cầu của khách hàng đề ra chứ không thể hiểu và xử lý được tất cả các case mà bạn tạo ra trên chính code của mình. Vậy mà khi bạn không xử lý cẩn thận, hoặc chỉ quan tâm rằng sản phẩm đã chạy, không có Test Script cẩn thận dẫn đến sau này khi mà dự án lớn dần, bạn phát triển sẽ dẫn đến rất nhiều conflict do không có các test case đảm bảo các trường hợp xảy ra lỗi của code, lỗi nọ chồng chéo lỗi kia, dẫn đến những lỗi mà bạn không hiểu tại sao lại sai, và QA cũng rất khó để có thể tái hiện cho bạn vì có thể rơi vào rất nhiều case khó để sửa, xa hơn nữa là bạn phải thay đổi toàn bộ phần code đó để tránh lỗi và thích hợp với phần task tiếp theo bạn muốn phát triển.

Vậy chúng ta cần phải làm gì để có thể tránh được những lỗi như vậy?

Sẽ có rất nhiều cách để khắc phục những lỗi như vậy như là review chéo, kiểm tra những đoạn code dễ xảy ra lỗi tìm cách thay đổi, v..v.. Nhưng trong bài viết này mình muốn tập trung đến một cách đó là sử dụng các phương pháp test trong project Rails Unit Testing hay Integration Testing, Functional Testing.

Đặc biệt với Project Ruby On Rails thì có một gem được các developer sử dụng nhiều đó là RSpec, kết hợp với nhiều gem khác như (Capybara, shoulda-matchers v..v..) để có thể tạo ra các test case và unit test một cách dễ dàng hơn rất là nhiều.

Quan điểm test/test case thì cần những gì?

Chắc hẳn với mỗi người sẽ có một cách tiếp cận với việc test khác nhau, và có cách suy nghĩ khác nhau về cách thức test, nhưng sau khi tham khảo khá nhiều và theo kinh nghiệm của mình thì để test tối ưu nhất, có thể sử dụng cho Ruby TDD lẫn BDD

• Test phải đáng tin cậy
• Test phải dễ viết, gọn
• Test phải dễ hiểu, dễ sửa chữa

Tuy nhiên để đảm bảo được những điều trên mọi người cũng nên tránh những việc này

• Không cần phải tập trung vào tốc độ, đôi khi việc vội vàng có thể tạo ra những hậu quả khôn lường.
• Không cần quá tập trung và quan tâm vào việc refactor hay DRY trong code test.

Việc làm như trên sẽ có thể cải thiện được rất nhiều những lỗi tiềm ẩn có thể xảy ra trong quá trình code tiếp các phần tiếp theo của dự án, việc tạo ra phần test code như thế này có thể bạn sẽ có các bài test và chúng đáng tin cậy, dễ hiểu, ngay cả khi chúng không được tối ưu hóa một cách tuyệt vời.

Trong series này sẽ có những gì?

Để đem đến cho các bạn có một cái nhìn tốt nhất, khái quát nhất mình sẽ đem đến 4 phần cơ bản trong việc test (có thể sẽ được mở rộng hơn)

1. Setting up RSpec
2. Model specs
3. Controller specs
4. Request specs