Tài nguyên để phát triển dựa trên thử nghiệm trong các ứng dụng web? [đóng cửa]


15

Tôi muốn thử và triển khai một số TDD trong các ứng dụng web của chúng tôi để giảm hồi quy và cải thiện chất lượng phát hành, nhưng tôi không tin vào việc kiểm tra tự động có thể thực hiện tốt như thế nào với các ứng dụng web mượt mà.

Tôi đã đọc và thử TDD và thử nghiệm đơn vị, nhưng các ví dụ là 'rắn' và các chức năng khá đơn giản như bộ chuyển đổi tiền tệ, v.v.

Có tài nguyên nào có thể giúp với đơn vị kiểm tra nội dung và hệ thống xuất bản không? Làm thế nào về đơn vị kiểm tra một giỏ hàng / cửa hàng (sản phẩm vật lý và trực tuyến)? AJAX?

Googling cho "Phát triển dựa trên thử nghiệm Web" chỉ cho tôi các bài viết cũ từ nhiều năm trước, bao gồm các ví dụ tương tự về chức năng giống như máy tính hoặc các cuộc thảo luận về lý do tại sao TDD tốt hơn bất cứ điều gì (không có ví dụ nào).


1
các công cụ có sẵn sẽ phụ thuộc vào ngôn ngữ. bạn đang sử dụng ngôn ngữ nào?
Alb

Tôi nhận ra điều đó - nhưng tôi đã tìm kiếm nhiều hơn cho các bài viết thảo luận và bài tiểu luận hơn là các công cụ cụ thể. Tôi biết những công cụ nào có sẵn, nhưng muốn tìm hiểu cách sử dụng chúng tốt nhất cho các ứng dụng điều khiển phía trước.
HorusKol

Câu trả lời:


2

Từ chối trách nhiệm lớn: Tôi chưa xây dựng bất kỳ ứng dụng web nào và tôi chưa thử nghiệm bất kỳ ứng dụng web nào. Sau đây chỉ là những mẩu thông tin tôi đã hấp thụ trong những lần đi ngẫu nhiên trong phạm vi thông tin.

Xây dựng ứng dụng web của bạn theo cách sao cho có thể kiểm tra các quy tắc kinh doanh một cách cô lập. Nếu bạn thấy mình đang thử nghiệm các quy tắc kinh doanh thông qua giao diện người dùng thì có lẽ đã đến lúc nghĩ về việc thiết kế lại.

Khi nói đến việc kiểm tra giao diện người dùng, hãy thay thế các quy tắc kinh doanh của bạn bằng các triển khai giả đáp ứng theo những cách có thể dự đoán được.

Hai quy tắc trên được lấy từ bài nói chuyện của Bob Martin tại RailsConf 2010 . Cuộc nói chuyện không phải là về TDD và phần mà anh ấy đề cập đến việc kiểm tra là ngắn và ở đâu đó ở giữa.

Có các công cụ như JsUnit , JSSpec , YUI Test để kiểm tra JavaScript và SeleniumWatir để kiểm tra UI.

Các Bookshelf Pragmatic có một vài cuốn sách bao gồm thử nghiệm các ứng dụng web. Danh sách các sách được gắn thẻ Kiểm tra có tại http://www.pragprog.com/c chuyên / design . Các sách thử nghiệm ứng dụng web thực dụng Bookshelf chủ yếu tập trung vào Ruby và Rails nhưng nên được áp dụng rộng rãi.


Một vấn đề lớn với thiết kế web là kiểm tra CSS - một quy tắc CSS mới có thể có những hậu quả không lường trước được, nhưng chỉ trên một trang có nội dung cụ thể ... Bạn có thể kiểm tra đơn vị đó không?
HorusKol

Câu hỏi hay. Tôi muốn đề nghị đây là một phần của thử nghiệm giao diện người dùng của bạn. Bạn phát triển các bài kiểm tra của mình để bao gồm các nội dung trang khác nhau mà bạn mong đợi (và một số ít bạn không mong đợi) và viết các chấp nhận của bạn một cách thích hợp. Sau đó, khi bạn giới thiệu các quy tắc CSS mới, kiểm tra giao diện người dùng của bạn sẽ làm nổi bật bất kỳ hồi quy nào. Có thể quá trình này quá tốn thời gian và bạn có thể được phục vụ tốt hơn bằng cách nhờ ai đó thực hiện kiểm tra QA trên trang web và báo cáo sự cố.
Anthony Cramp

3

Test-Driven JavaScript Development là một cuốn sách thực sự hay của Christian Johansen, nhà phát triển đằng sau Sinon.jsBuster.js , bao gồm các chủ đề như (lấy từ trang web):

  • Hiểu thử nghiệm đơn vị và TDD
  • Lựa chọn khung kiểm tra đơn vị phù hợp
  • Xây dựng API sạch hơn, JavaScript được mô đun hóa và mạnh mẽ
  • Liên tục cải thiện mã thông qua tái cấu trúc
  • Năm phiên TDD thực tế: Ajax, thao tác DOM, Node.js và hơn thế nữa
  • Tham quan theo hướng thử nghiệm tới JavaScript dành cho nhà phát triển không quen thuộc với ngôn ngữ

Hiện tại chúng tôi sử dụng Sinon.js với Mocha, nhưng sẵn sàng chuyển sang Buster.js, vì các tính năng của nó rất gọn gàng!


1

Trong một dự án tôi đã làm gần đây, nhà phát triển chính đã quyết định sử dụng Unity để việc chế nhạo và TDD được đơn giản hóa trong một ứng dụng web lớn - Tôi cho rằng việc sử dụng Unity thường sẽ đi kèm với TDD là một ứng dụng web.

Điều tra thử nghiệm đơn vị CMS có thể dẫn đến ngõ cụt vì đơn giản là không có điều gì hợp lý để chế giễu. Tôi không thấy những gì có thể được kiểm tra mà không chế nhạo lưu lượng truy cập http đến các trang - và tại thời điểm đó, kiểm tra có rất ít giá trị.

Tôi nghĩ một quy tắc hữu ích với các ứng dụng web là nếu nó có thể sử dụng giả để giảm độ phức tạp thì có lẽ nó có thể được kiểm tra đơn vị.

Vì vậy, trong một ứng dụng web, bạn có thể giả định cơ sở dữ liệu của mình để kiểm tra các phần khác nhau của lớp hoặc mô hình truy cập dữ liệu của bạn; bạn có thể giả định đầu vào của người dùng để kiểm tra đơn vị xem hoặc giao diện người dùng, v.v.


0

Tôi đã viết một cuốn sách về TDD để phát triển web với Python + Django. nó bao gồm TDD, cả với các thử nghiệm từ đầu đến cuối / chức năng (selen) và thử nghiệm "đơn vị" cấp thấp hơn. Tôi cũng trình bày các thực tiễn phát triển hiện đại như cách tích hợp git vào quy trình công việc của bạn, cách triển khai đến máy chủ và tự động hóa và kiểm tra rằng, tích hợp liên tục, giả lập và kiểm tra cách ly, và nhiều hơn nữa:

http://www.obeythetestinggoat.com/

(hoặc http://shop.oreilly.com/product/0636920051091.do )


Liên kết bị hỏng
Keldon Alleyne
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.