Những gì cần được thử nghiệm trong Javascript?


12

Tại nơi làm việc, chúng tôi mới bắt đầu sử dụng một ứng dụng dựa trên Javascript (thực tế là sử dụng Coffeescript, nhưng vẫn), trong đó tôi đã triển khai một hệ thống kiểm tra tự động bằng JsTestDriver và vải.

Chúng tôi chưa bao giờ viết một cái gì đó với nhiều Javascript này, vì vậy cho đến bây giờ chúng tôi chưa bao giờ thực hiện bất kỳ thử nghiệm Javascript nào. Tôi không chắc chính xác những gì chúng ta nên kiểm tra trong các bài kiểm tra đơn vị của chúng tôi. Chúng tôi đã viết các plugin JQuery cho nhiều thứ khác nhau, vì vậy rõ ràng là chúng nên được xác minh tính chính xác nhất có thể với JsTestDriver, nhưng mọi người khác trong nhóm của tôi dường như cũng nghĩ rằng chúng tôi cũng nên thử nghiệm Javascript cấp độ trang.

Tôi không nghĩ rằng chúng ta nên thử nghiệm Javascript cấp trang dưới dạng thử nghiệm đơn vị, nhưng thay vào đó sử dụng một hệ thống như Selenium để xác minh mọi thứ hoạt động như mong đợi. Lý do chính của tôi cho điều này là tại thời điểm này, các thử nghiệm Javascript ở cấp độ trang được đảm bảo không thành công thông qua JsTestDriver, vì họ đang cố gắng truy cập các phần tử trên DOM không thể tồn tại.

Vì vậy, những gì cần được thử nghiệm trong Javascript?


3
Bạn cô lập bất kỳ mã javascript nào bạn đã viết thành các mô-đun. Sau đó, bạn chỉ cần kiểm tra đầu vào và đầu ra của các mô-đun. Bất kỳ mô-đun nào liên quan đến DOM có nghĩa là bạn phải kiểm tra DOM. Sử dụng một công cụ tốt hơn sau đó jsTestDriver.
Raynos

Bạn nên thử nghiệm đơn vị logic kinh doanh. Nếu logic kinh doanh và các yếu tố của bạn trên DOM được đan xen thì bạn có một lỗi thiết kế. Tóm tắt càng nhiều logic kinh doanh từ các yếu tố trang càng tốt để nó có thể được kiểm tra đúng đơn vị. Để xác minh tương tác thành phần DOM, bạn nên sử dụng Selenium.
maple_shaft

1
@NathanHoad Bạn viết các bài kiểm tra đơn vị chạy trên chính trình duyệt, nodeunit, qunit và hoa nhài là những công cụ hợp lý. Khi chạy trong trình duyệt, bạn có DOM. Bạn có thể sử dụng một công cụ như testling để tự động kiểm tra trình duyệt.
Raynos

1
Cảm ơn. Tôi đã tìm kiếm jsTestDriver vì nó tuyên bố có thể chạy trên trình duyệt, trong khi về mặt kỹ thuật, tôi đã phát hiện ra không giống như chạy với QUnit. Tôi đã làm việc trên công cụ của riêng mình tại thời điểm sử dụng QUnit, với bảng điều khiển thanh công cụ gỡ lỗi Django tùy chỉnh. Sử dụng Selenium tôi sẽ có thể phát hiện các bài kiểm tra thất bại. Ngoài ra, tôi nghi ngờ ông chủ của tôi sẽ trả tiền cho việc thử nghiệm, mặc dù nó trông khá tốt!
Nathan Hoad

Câu trả lời:


4

Kiểm tra mọi thứ bạn có thể.

Logic thuần túy có thể được kiểm tra dễ dàng.

Nếu mã của bạn tương tác với DOM hoặc mạng, điều đó khó hơn nhiều.

Nếu bạn có thể trừu tượng hóa một đoạn mã để làm việc trên một phần tử DOM tùy ý thay vì một phần tử cụ thể, thì bạn có thể kiểm tra nó dễ dàng hơn. (Tạo phần tử để làm việc trên một tham số).

Mã sử ​​dụng Ajax có thể được kiểm tra bằng cách gọi hàm gọi lại với dữ liệu cố định. Tôi đã có một số thử nghiệm trong đó tôi ghi đè $.ajaxbằng chức năng của riêng tôi. Chỉ cần chắc chắn rằng bạn đặt lại cái thật khi bạn hoàn thành!

Những gì bạn sẽ tìm thấy là "javascript cấp trang" thực sự có nghĩa là "mã được ghép chặt chẽ" và nếu bạn tách rời các phần của mã, bạn có thể kiểm tra chúng một cách độc lập.

(Selenium không phải là một công cụ kiểm tra đơn vị. Thật tuyệt vời cho các kịch bản cấp cao, nhưng bạn không thể lái thử với nó và nó không hoạt động trong một môi trường biệt lập.)


hoa nhài có thể chế nhạo các cuộc gọi chức năng và dữ liệu phản hồi, bạn có thể xem xét điều đó thay vì ghi đè các chức năng.
Steve

Tôi nên làm rõ - chúng tôi có chức năng và như vậy trên mỗi trang. Tôi đã nói nhiều hơn về việc kiểm tra mã thực thi bên trong $(document).ready(...).
Nathan Hoad

1
Tất cả chỉ là vấn đề lớn như thế nào .... :-) Tôi cảm thấy như bạn sẽ có thể đưa nó xuống một chức năng có tên duy nhất cũng được thử nghiệm. Sau đó, mã chưa được kiểm tra của bạn là một dòng duy nhất. (Bây giờ đó là một mục tiêu, không phải là nhất định. Trong thực tế, tôi luôn có nhiều hơn một dòng mã chưa được kiểm tra.)
Sean McMillan

@SeanMcMillan - Tôi thấy rất khó kiểm tra các phần của ứng dụng chỉ ảnh hưởng đến DOM, ví dụ, một hàm chỉ liên kết một số sự kiện với một số thành phần DOM. Làm thế nào bạn sẽ kiểm tra rằng những sự kiện đó đã được viết đúng? không phải thứ gì đó kiểm tra đơn vị có thể làm, nhưng nhấp và kiểm tra trình duyệt thực (sử dụng selen hoặc bất cứ thứ gì)
vsync

@vsync: Bạn có thể kiểm tra xem, một trình xử lý nhấp chuột đã được gắn vào một phần tử DOM cụ thể khá dễ dàng. Tôi không nghĩ có thể kiểm tra rằng 'nhấp chuột' là trình xử lý phù hợp và bạn đã gắn nó với phần tử phù hợp.
Sean McMillan

5

Các thuật toán thử nghiệm. Các phần liên quan chặt chẽ với GUI phụ thuộc nhiều hơn vào trình duyệt cụ thể, do đó phải được kiểm tra bằng cách sử dụng các dụng cụ giống như selen.

Tất nhiên, mã của bạn phải chứa các thuật toán như một đoạn mã bị cô lập, nếu không thì việc kiểm thử đơn vị là gần như không thể.

plugin jquery, btw, không dễ kiểm tra đơn vị.


Tất cả những điểm tốt! Tôi đồng ý rằng họ cũng không dễ dàng kiểm tra đơn vị, tùy thuộc vào cách họ viết.
Nathan Hoad

-1

Tôi đã từng làm việc với Java và từ những gì tôi thấy việc kiểm thử đơn vị Java dễ hơn kiểm thử đơn vị JavaScript vì Java cứng hơn.

Tôi được bán trên sự phát triển dựa trên thử nghiệm đó là điều tốt nhất vì vậy tôi cũng đang tìm hiểu cách kiểm tra đơn vị JavaScript. Trong Java, tôi đã mô phỏng mã tạo kết nối tới cơ sở dữ liệu, Đối tượng truy cập dữ liệu và tôi so sánh mã đó với mã JavaScript thay đổi DOM và mã thực hiện cuộc gọi AJAX đến máy chủ.

Điều tôi nhận được là dường như với tôi rằng những gì nên được kiểm tra là logic rõ ràng. Ví dụ: bạn không muốn thực hiện cuộc gọi AJAX khi bạn chạy thử nghiệm đơn vị vì (a) bạn cần máy chủ đang chạy và (b) nó chậm và một trong những hướng dẫn của thử nghiệm đơn vị là nó cần phải siêu nhanh để các nhà phát triển không tránh chạy chúng như mọi phút.

Một hướng dẫn khác là quy trình tích hợp liên tục để gửi e-mail nói rằng nó đã tìm thấy một bài kiểm tra đơn vị thất bại.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.