Làm cách nào để trích dẫn một công việc với PHPUnit?

Tôi đã làm lập trình trang web trong 15 năm và PHP trong 5 năm qua hoặc lâu hơn. Tôi đã luôn luôn viết mã rắn. TUY NHIÊN, tôi có một khách hàng đang khăng khăng 80% mã đang được thử nghiệm. Vì ứng dụng khách LUÔN LUÔN, tôi dự định sử dụng PHP_CodeSniffer để đảm bảo mã của tôi trông đúng và PHPUnit để kiểm tra đơn vị của tôi. Tôi hy vọng sẽ học được điều gì đó thông qua trải nghiệm này.

Đây có phải là những công cụ phù hợp để sử dụng? Bao nhiêu thời gian liên quan đến việc thiết lập PHPUnit và viết mã bổ sung? Tôi sẽ mất khoảng 8 tuần để viết các trang web và tự kiểm tra như tôi đã làm trong quá khứ. Nếu tôi thêm 4 ngày nữa (10%) cho thử nghiệm đơn vị (PHPUnit), như vậy đã đủ chưa? Suy nghĩ? Gợi ý? Cảm ơn.

Trong một dòng: nó phụ thuộc vào cách bạn làm việc. Tôi nghĩ rằng 10% là quá ít. Nó nên có ít nhất 25%, nếu không 40%, nếu không 60%, nếu không nhiều hơn.

Đầu tiên, tôi rất đồng ý với khách hàng của bạn ở đó. Kiểm tra đơn vị là một phần thiết yếu của một sản phẩm mạnh mẽ, dễ bảo trì, dễ gỡ lỗi.

Tôi sẽ nói từ những gì tôi biết. Tôi sử dụng TDD (Phát triển dựa trên thử nghiệm) cho hầu hết các dự án. TDD về cơ bản làm cho bạn viết các bài kiểm tra trước khi mã thực tế. Họ thiết lập một bộ tiêu chí chấp nhận mà sản phẩm cuối cùng cần đáp ứng. Thông thường, bạn sẽ dành từ 50% đến 70% thời gian để viết bài kiểm tra và phần còn lại để thực hiện mã để làm cho chúng vượt qua.

Mặc dù nghe có vẻ ngớ ngẩn và / hoặc to lớn, tôi có thể đảm bảo với bạn rằng nó không phải. Đây là lý do tại sao:

• Bạn sẽ có thể tìm ra (các) mẫu kiến ​​trúc tốt nhất để sử dụng trong khi viết các bài kiểm tra. Theo cách này, khi bạn bắt đầu mã hóa, kiến ​​trúc ứng dụng sẽ thay đổi tối thiểu (bởi vì tất cả chúng ta đều biết việc làm lại một kiến ​​trúc ứng dụng tốn kém như thế nào).
• Bạn chỉ viết mã để làm cho các bài kiểm tra vượt qua (do đó làm cho sản phẩm cuối được chấp nhận). Bạn sẽ không dành thời gian lập trình các tính năng vô dụng / ngoài phạm vi.
• Bằng cách có ít mã hơn (tức là: chỉ mã mà bạn thực sự cần), nó sẽ ít bị lỗi hơn. (Ít mã hơn = ít lỗi hơn).
• Nếu bạn phạm sai lầm, và bạn sẽ làm được, sẽ mất ít thời gian hơn để tìm hiểu tại sao có vấn đề và vấn đề nằm ở đâu. Nếu các bài kiểm tra được viết đúng, điều đó có nghĩa là một lỗi duy nhất sẽ gây ra một lỗi duy nhất, không phải là phản ứng dây chuyền. Bằng cách này, bạn có thể dễ dàng xác định nguồn gốc của vấn đề trong vài phút, nếu không phải là vài giây.
• Sẽ mất ít thời gian hơn để thực hiện mã thực tế với các bài kiểm tra đơn vị. Ngay khi một bài kiểm tra thất bại, bạn biết rằng có điều gì đó không ổn. Bạn không phải thực hiện qua lại với khách hàng để sửa lỗi.
• Cuối cùng, bạn sẽ phải thực hiện lại với khách hàng để sửa lỗi, vì không có gì có thể bắt lỗi 100%. Tuy nhiên, bạn có thể dễ dàng bắt 95% nếu không muốn nói là nhiều hơn.

PHPUnit là công cụ thực tế để kiểm tra đơn vị PHP và nó rất tốt ở đó. Tôi chưa sử dụng PHP_CodeSniffer nhiều. Tuy nhiên, tôi nghĩ rằng nếu bạn đang làm việc một mình, có lẽ bạn không cần nó. Nó hữu ích hơn trong một nhóm để đảm bảo mã trông giống nhau cho dù ai đã mã hóa nó.

Đạo cụ cho bạn vì có thái độ rằng bạn sẽ học được điều gì đó từ kinh nghiệm này. Tôi chắc chắn bạn sẽ làm được.

Điều đầu tiên bạn nên học là sự cần thiết của kiểm tra đơn vị không liên quan gì đến việc bạn có kinh nghiệm như thế nào . Nhà phát triển tốt nhất cũng sẽ là một trong những người thử nghiệm đơn vị tốt nhất:

Bill Venners: Bạn nói trong cuốn sách Tái cấu trúc của bạn: "Nếu bạn muốn tái cấu trúc, điều kiện tiên quyết cần thiết là phải có các bài kiểm tra vững chắc." Điều đó có nghĩa là nếu bạn không có bài kiểm tra, bạn không nên cấu trúc lại?

Martin Fowler: Bạn nên nghĩ về nó như đi bộ trên đường mà không có lưới. Nếu bạn giỏi đi bộ trên dây, và nó không cao lắm, thì bạn có thể thử nó. Nhưng nếu bạn chưa bao giờ đi một đoạn đường hẹp trước đây và trên Thác Niagara, bạn có thể muốn có một mạng lưới tốt.

^{Từ http://www.artima.com/intv/refactorP.html}

Tôi đã từng viết PHP mà không có bài kiểm tra đơn vị. Sau đó, sau nhiều năm thực hành thử nghiệm đơn vị trong Java, tôi thấy rằng tôi không thể làm việc trên bất kỳ thứ gì phức tạp hơn nhiều so với các trang đơn lẻ trong PHP mà không thử nghiệm đơn vị. Nguyên nhân? Năng suất . Nếu không có thử nghiệm đơn vị, tôi không thể tái cấu trúc một cách tự tin - điều này có nghĩa là A) Tôi sẽ phải xé nát nhiều thứ hơn và làm lại mọi thứ ngay từ đầu, hoặc B) , tôi sẽ phải đối phó với mã kế thừa xấu xí.

Khi bạn đang thực hiện một giá thầu, bạn cần phải tính đến thời gian để kiểm tra? Có . Có vẻ trực quan rằng sẽ mất nhiều thời gian hơn ? Vâng, một lần nữa . Bạn có thể, như một số câu trả lời khác đã ước tính gần đúng, cần ước tính lớn hơn 50 - 100% so với không có bài kiểm tra đơn vị.

Tuy nhiên!...

• Bạn sẽ bắt và giải quyết các lỗ đặc tả trước đó
• Điều đó có nghĩa là bạn sẽ phát triển thành một đặc điểm kỹ thuật sạch hơn và vững chắc hơn
• Bạn sẽ có thể phản hồi nhanh chóng và tự tin với các thay đổi cụ thể
• Bạn sẽ có ít lỗi hơn
• Lỗi của bạn sẽ được phát hiện sớm hơn và dễ dàng hơn để khắc phục

Và kết quả là, ước tính của bạn sẽ chính xác hơn . Nếu bạn tính phí hàng giờ, bạn sẽ gây ấn tượng với khách hàng của mình nhiều hơn và có thể tăng giá của bạn. Nếu bạn tính lãi suất cố định, bạn sẽ kiếm được nhiều tiền hơn mỗi giờ.

Nếu không có thử nghiệm, ước tính của bạn rất có thể là một crapshoot. Lỗi, đơn đặt hàng thay đổi và xác định lại đều khủng khiếp để ước tính chính xác. Kiểm tra là chìa khóa để giảm thiểu tác động của cả ba!

Không có câu trả lời dễ dàng về việc bạn sẽ mất bao lâu.

Nhưng như một quy tắc cơ bản, nếu đó là một dự án ngắn: Tôi muốn nói rằng sự phát triển cùng với thử nghiệm đơn vị tốt sẽ mất 1,75-2 lần miễn là phát triển mà không cần thử nghiệm đơn vị. Đối với các dự án dài hơn có thể 25-30%?

Tôi đề nghị làm bài kiểm tra đơn vị trước khi bạn viết mã của bạn. Theo cách này, việc xây dựng giàn giáo thử nghiệm đơn vị thực sự trở thành một phần trong quy trình thiết kế của bạn, và vì vậy bạn không nên cân nhắc rằng bạn đang mất thời gian để thử nghiệm đơn vị, mà thay vào đó, việc xây dựng thử nghiệm đơn vị đang giúp bạn thiết kế sản phẩm tuyệt vời và sự tồn tại của thử nghiệm đó sau khi bạn xây dựng nó giúp bạn dễ dàng hơn để đảm bảo rằng nó vẫn như vậy. Phải viết bài kiểm tra đơn vị trước tiên là điều tuyệt vời trong việc giúp tập trung vào các yêu cầu thực tế, cho chúng tôi một cách rõ ràng để kiểm tra xem chúng tôi đã hoàn thành chưa (vượt qua bài kiểm tra đơn vị) và giúp chúng tôi "kiểm tra sớm và kiểm tra thường xuyên".

Đối với PHPUnit .... Đã một thời gian kể từ khi tôi sử dụng nó, ấn tượng của tôi là nó rất mạnh nhưng có lẽ cần thêm một số công việc trước khi nó thực sự được đánh bóng.

Tuy nhiên, nếu có một điều tôi muốn liên lạc ở đây: Vui lòng không xem Kiểm thử đơn vị như một hình thức đơn thuần ở cuối dự án của bạn. Nếu đó là tất cả, theo tôi, nó là vô giá trị.

Các câu trả lời cho đến nay khá kỹ lưỡng vì vậy tôi sẽ chỉ thêm một điểm không được đề cập: thời gian thêm do sử dụng PHPUnit sẽ là

1. ban đầu cao hơn kể từ khi bạn học nó, và
2. giảm thời gian phát triển không kiểm tra khi bạn có được sự tự tin với nó.

Các lớp mô hình thử nghiệm đơn vị không đối phó với việc trình bày là khá đơn giản. Bạn viết một bài kiểm tra cho mỗi lớp và trong các trường hợp kiểm tra đó, bạn có thể trực tiếp khởi tạo và định cấu hình một đối tượng để kiểm tra một phương thức / tính năng cụ thể. Khi bạn đã thiết lập và chạy PHPUnit, bạn sẽ có thể làm cho các thử nghiệm này hoạt động nhanh chóng.

Các trang web thử nghiệm đơn vị có thể khó khăn hơn. Nếu bạn sử dụng Zend Framework, Symfony, Smarty hoặc bất kỳ công cụ MVC nào khác, việc PHPUnit chơi tốt với chúng có thể mất nhiều thời gian hơn. Chúng tôi sử dụng Zend Framework và tôi đã dành một lượng thời gian đáng kể để xây dựng các lớp cơ sở để kiểm tra các bộ điều khiển và xem các tập lệnh riêng rẽ. Với quy mô của dự án này, có lẽ bạn nên bắt đầu với ControllerTestCase.