Phát triển ngôn ngữ thử nghiệm đa ngôn ngữ

Câu hỏi ngắn: Làm thế nào để bạn theo dõi Phát triển dựa trên thử nghiệm trong một dự án mở rộng nhiều ngôn ngữ?

Cụ thể, tôi đang viết một ứng dụng web sử dụng JavaScript và PHP và tôi muốn tuân theo các nguyên tắc TDD, nhưng tôi không chắc cách tích hợp chúng. Tôi có chạy các bộ thử nghiệm riêng biệt cho các phần JS và PHP không và sử dụng các mô phỏng trong bộ JS để mô phỏng các phản hồi của máy chủ? Có một kỹ thuật để kiểm tra đơn vị cả hai thành phần trong một lần chạy không?

Đây là trải nghiệm đầu tiên của tôi khi sử dụng Phát triển dựa trên thử nghiệm, vì vậy mọi lời khuyên bạn có thể chia sẻ về cách làm cho nó bớt khó khăn hơn sẽ rất tuyệt. Lý do tôi chọn nó là ngay khi tôi hoàn thành một nguyên mẫu, các yêu cầu đã thay đổi, buộc tôi phải thay đổi thiết kế của mình. Tôi hình dung nếu tôi bắt đầu lại, tôi muốn viết mã mở rộng hơn với thử nghiệm hồi quy tích hợp ngay từ đầu.

Tôi đang viết các bài kiểm tra PHP của mình trong SimpleTest và các bài kiểm tra JavaScript của tôi trong JsTestDriver. Tôi đã quen với các mô hình hướng đối tượng, vì vậy tôi đã có một vài lớp trong PHP và tôi đang làm một cái gì đó tương tự trong JavaScript bằng cách sử dụng kế thừa nguyên mẫu. Tôi cũng đã bắt đầu đọc cuốn sách này về TDD bằng Python và cuốn này về TDD bằng JavaScript , nhưng từ tất cả những gì tôi đã thấy, những điều này không mô tả việc kiểm tra một ứng dụng đầy đủ (ngoài việc sử dụng một cái gì đó như Selenium hoặc trình điều khiển web khác để thực hiện kiểm tra chấp nhận front-end. Có phải TDD không bị cắt cho các nhà phát triển full-stack?

Có một kỹ thuật để kiểm tra đơn vị cả hai thành phần trong một lần chạy không?

Điều đó thực sự sẽ trái ngược với thử nghiệm đơn vị - thử nghiệm đơn vị, đặc biệt là theo kiểu TDD, có nghĩa là thử nghiệm các thành phần của bạn một cách cô lập . Do đó, câu trả lời là có, "chạy các bộ thử nghiệm riêng biệt cho các phần JS và PHP ", nếu không nó không phải là thử nghiệm đơn vị và không phải là TDD.

Tất nhiên, kiểm tra tích hợp tự động có thể kiểm tra "cả hai thành phần trong một lần chạy" và bạn có thể sử dụng chính xác các công cụ bạn đã đề cập (như Selenium). Nhưng đó là những thử nghiệm phức tạp hơn, được phát triển bên ngoài các chu trình TDD.

Điều quan trọng là phân biệt giữa TDD và ATDD . AT là viết tắt của " kiểm tra chấp nhận " và điều này đề cập đến sự phát triển nơi bạn bắt đầu với thử nghiệm chấp nhận, có khả năng kiểm tra toàn bộ ngăn xếp. Điều này đôi khi cũng được gọi là "phát triển theo hướng kiểm tra bên ngoài". Khi mọi người nói về TDD, "T" có thể đề cập cụ thể đến các bài kiểm tra đơn vị .

Một phần quan trọng của các bài kiểm tra đơn vị là cách ly đơn vị được kiểm tra khỏi các phụ thuộc của nó. Điều này mang lại cho bạn hai lợi ích rất quan trọng:

• Bạn có thể thực hiện các bài kiểm tra của mình cực kỳ nhanh, vì vậy bạn có thể chạy chúng rất thường xuyên như một phần của chu kỳ phản hồi rất ngắn. Thay vì chạy chúng, mỗi giờ, bạn sẽ có thể chạy tất cả các bài kiểm tra đơn vị của mình sau mỗi thay đổi nhỏ, vì vậy bạn ngay lập tức nhận được phản hồi của họ về việc thay đổi đó có phá vỡ điều gì không.

• Bài kiểm tra của bạn có thể được nhắm mục tiêu tại một hành vi rất cụ thể. Nếu một trong số chúng thất bại, bạn sẽ có thể xác định gần như ngay lập tức bản chất chính xác của lỗi mà thử nghiệm đang chỉ ra.

Do tầm quan trọng của sự cô lập này, bạn sẽ tự động muốn các bài kiểm tra bị giới hạn ở các đơn vị nhỏ hơn nhiều so với ranh giới ngôn ngữ của bạn buộc bạn phải tham gia. Mặc dù đó không phải là một quy tắc khó và nhanh, nhưng bạn thường mong đợi một lớp duy nhất là một đơn vị có thể kiểm tra được. Vì vậy, về mặt TDD, vấn đề ngôn ngữ ít nhiều không liên quan.

Mặt khác, nếu bạn muốn thực hiện ATDD, hãy đảm bảo rằng bạn xem xét các tài nguyên cho việc này một cách cụ thể (nó thường được thực hiện như một phần của BDD, do đó, hãy nhìn vào các công cụ được nhắm mục tiêu vào đó). Đây là nơi mà một thứ như Selenium tự nhiên sẽ phù hợp. Thông thường, khi thực hiện ATDD, bạn vẫn viết các bài kiểm tra đơn vị, và trên thực tế để vượt qua từng bài kiểm tra chấp nhận, bạn cũng có thể kiểm tra việc thực hiện bằng các bài kiểm tra đơn vị. Vì vậy, ngay cả khi bạn muốn làm ATDD, hiểu cách viết bài kiểm tra đơn vị vẫn rất quan trọng.

Ngoài ra, bạn không phải sử dụng TDD cho toàn bộ ứng dụng. TDD như một phương pháp phát triển phù hợp hơn cho các phần logic của ứng dụng. Các phần đòi hỏi một liên lạc thử nghiệm hơn, như đã nói, thiết kế của frontend, xác nhận các tương tác hoặc miền cơ sở dữ liệu được thực hiện tốt hơn theo kiểu truyền thống như bạn chưa biết nếu đó sẽ là phiên bản cuối cùng.

Nhưng logic của ứng dụng sẽ không thay đổi trong tương lai và nếu nó phải đối mặt với creep yêu cầu đáng sợ. Điều đó làm cho nó hoàn hảo cho một bộ các bài kiểm tra hồi quy để tạo sự tự tin mỗi khi thực hiện thay đổi mã, đó là mục tiêu cuối cùng của TDD.

Chú Bob giải thích cách này tốt hơn tôi. https://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html