Kiểm tra đơn vị là gì? [đóng cửa]

Tôi đã thấy nhiều câu hỏi hỏi 'làm thế nào' để kiểm tra đơn vị bằng một ngôn ngữ cụ thể, nhưng không có câu hỏi nào hỏi 'cái gì', 'tại sao' và 'khi nào'.

• Nó là gì?
• Nó làm gì cho tôi?
• Tại sao tôi nên sử dụng nó?
• Khi nào tôi nên sử dụng nó (cũng có khi không)?
• Một số cạm bẫy và quan niệm sai lầm phổ biến là gì

Kiểm thử đơn vị, đại khái là, kiểm tra các bit của mã của bạn một cách tách biệt với mã kiểm tra. Những lợi thế trước mắt xuất hiện trong tâm trí là:

• Chạy các bài kiểm tra trở nên tự động hóa và có thể lặp lại
• Bạn có thể kiểm tra ở mức độ chi tiết hơn nhiều so với kiểm tra điểm và nhấp qua GUI

Lưu ý rằng nếu mã kiểm tra của bạn ghi vào một tệp, mở kết nối cơ sở dữ liệu hoặc thực hiện một cái gì đó qua mạng, thì nó được phân loại thích hợp hơn là kiểm tra tích hợp. Kiểm tra tích hợp là một điều tốt, nhưng không nên nhầm lẫn với kiểm tra đơn vị. Mã kiểm tra đơn vị nên ngắn gọn, ngọt ngào và nhanh chóng để thực hiện.

Một cách khác để xem xét kiểm tra đơn vị là bạn viết các bài kiểm tra trước. Điều này được gọi là Phát triển dựa trên thử nghiệm (viết tắt là TDD). TDD mang lại lợi thế bổ sung:

• Bạn không viết mã "Tôi có thể cần mã này trong tương lai" - chỉ đủ để làm cho các bài kiểm tra vượt qua
• Mã bạn đã viết luôn được bao phủ bởi các bài kiểm tra
• Bằng cách viết bài kiểm tra trước, bạn buộc phải suy nghĩ về cách bạn muốn gọi mã, điều này thường cải thiện thiết kế mã trong thời gian dài.

Nếu bạn hiện không thực hiện kiểm tra đơn vị, tôi khuyên bạn nên bắt đầu với nó. Có được một cuốn sách hay, thực tế là bất kỳ cuốn sách xUnit nào cũng sẽ làm được vì các khái niệm có thể chuyển đổi rất nhiều giữa chúng.

Đôi khi viết bài kiểm tra đơn vị có thể gây đau đớn. Khi mọi chuyện trở nên như vậy, hãy cố gắng tìm ai đó giúp bạn và chống lại sự cám dỗ "chỉ viết mã chết tiệt". Kiểm tra đơn vị rất giống như rửa chén bát. Nó không phải lúc nào cũng dễ chịu, nhưng nó giữ cho nhà bếp ẩn dụ của bạn sạch sẽ, và bạn thực sự muốn nó sạch sẽ. :)

Chỉnh sửa: Một quan niệm sai lầm xuất hiện trong đầu, mặc dù tôi không chắc nó có phổ biến không. Tôi đã nghe một người quản lý dự án nói rằng các bài kiểm tra đơn vị đã khiến nhóm viết tất cả mã hai lần. Nếu nó trông và cảm thấy như vậy, tốt, bạn đã làm sai. Việc viết các bài kiểm tra thường không làm tăng tốc độ phát triển mà còn cung cấp cho bạn một chỉ báo "bây giờ tôi đã hoàn thành" tiện lợi mà bạn sẽ không có.

Tôi không đồng ý với Dan (mặc dù lựa chọn tốt hơn có thể là không trả lời) ... nhưng ...

Kiểm thử đơn vị là quá trình viết mã để kiểm tra hành vi và chức năng của hệ thống của bạn.

Rõ ràng các thử nghiệm cải thiện chất lượng mã của bạn, nhưng đó chỉ là lợi ích bề ngoài của thử nghiệm đơn vị. Những lợi ích thực sự là:

1. Giúp dễ dàng thay đổi triển khai kỹ thuật hơn trong khi đảm bảo bạn không thay đổi hành vi (tái cấu trúc). Mã thử nghiệm đơn vị chính xác có thể được tái cấu trúc / dọn dẹp mạnh mẽ với rất ít cơ hội phá vỡ bất cứ thứ gì mà không nhận thấy nó.
2. Cung cấp cho các nhà phát triển sự tự tin khi thêm hành vi hoặc thực hiện các bản sửa lỗi.
3. Tài liệu mã của bạn
4. Chỉ ra các khu vực mã của bạn được liên kết chặt chẽ. Thật khó để kiểm tra mã đơn vị được ghép chặt chẽ
5. Cung cấp phương tiện để sử dụng API của bạn và sớm tìm kiếm khó khăn
6. Chỉ ra các phương thức và các lớp không gắn kết

Bạn nên kiểm tra đơn vị vì lợi ích của bạn để cung cấp một sản phẩm có thể bảo trì và chất lượng cho khách hàng của bạn.

Tôi khuyên bạn nên sử dụng nó cho bất kỳ hệ thống nào, hoặc một phần của hệ thống, mô hình hóa hành vi trong thế giới thực. Nói cách khác, nó đặc biệt phù hợp để phát triển doanh nghiệp. Tôi sẽ không sử dụng nó cho các chương trình tiện ích / vứt đi. Tôi sẽ không sử dụng nó cho các phần của hệ thống có vấn đề để kiểm tra (UI là một ví dụ phổ biến, nhưng không phải lúc nào cũng như vậy)

Cạm bẫy lớn nhất là các nhà phát triển kiểm tra một đơn vị quá lớn hoặc họ coi một phương pháp là một đơn vị. Điều này đặc biệt đúng nếu bạn không hiểu Inversion of Control - trong trường hợp đó, các bài kiểm tra đơn vị của bạn sẽ luôn chuyển thành kiểm tra tích hợp đầu cuối. Kiểm tra đơn vị nên kiểm tra các hành vi cá nhân - và hầu hết các phương pháp có nhiều hành vi.

Quan niệm sai lầm lớn nhất là các lập trình viên không nên kiểm tra. Chỉ những lập trình viên xấu hoặc lười biếng mới tin điều đó. Anh chàng có nên xây mái nhà của bạn không kiểm tra nó? Bác sĩ có nên thay van tim không thử van mới? Chỉ có lập trình viên mới có thể kiểm tra mã của anh ta thực hiện những gì anh ta dự định làm (QA có thể kiểm tra các trường hợp cạnh - cách mã hoạt động khi được yêu cầu làm những việc mà lập trình viên không có ý định và khách hàng có thể thực hiện kiểm tra chấp nhận - mã có làm không những gì khách hàng đã trả cho nó để làm gì)

Sự khác biệt chính của kiểm tra đơn vị, như trái ngược với "chỉ mở một dự án mới và kiểm tra mã cụ thể này" là nó tự động , do đó có thể lặp lại .

Nếu bạn kiểm tra mã của mình theo cách thủ công, nó có thể thuyết phục bạn rằng mã đang hoạt động hoàn hảo - ở trạng thái hiện tại . Nhưng những gì về một tuần sau, khi bạn thực hiện một sửa đổi nhỏ trong đó? Bạn có sẵn sàng kiểm tra lại bằng tay bất cứ khi nào có bất cứ điều gì thay đổi trong mã của bạn không? Hầu hết có lẽ là không :-(

Nhưng nếu bạn có thể chạy thử nghiệm của mình bất cứ lúc nào, chỉ với một cú nhấp chuột, chính xác theo cùng một cách, trong vài giây , thì chúng sẽ hiển thị cho bạn ngay lập tức bất cứ khi nào có gì đó bị hỏng. Và nếu bạn cũng tích hợp các bài kiểm tra đơn vị vào quy trình xây dựng tự động của mình, chúng sẽ cảnh báo bạn về các lỗi ngay cả trong trường hợp một thay đổi dường như hoàn toàn không liên quan đã phá vỡ thứ gì đó ở một phần xa của cơ sở mã - khi nó thậm chí không xảy ra với bạn rằng có cần kiểm tra lại chức năng cụ thể đó

Đây là ưu điểm chính của kiểm tra đơn vị so với kiểm tra tay. Nhưng chờ đợi, có nhiều hơn nữa:

• kiểm thử đơn vị rút ngắn đáng kể vòng phản hồi phát triển : với một bộ phận kiểm tra riêng biệt, bạn có thể mất vài tuần để biết rằng có một lỗi trong mã của mình, đến lúc đó bạn đã quên nhiều bối cảnh, do đó bạn có thể mất hàng giờ để tìm và sửa lỗi; OTOH với các bài kiểm tra đơn vị, chu kỳ phản hồi được đo bằng giây và quá trình sửa lỗi thường diễn ra theo dòng "oh sh * t, tôi quên kiểm tra tình trạng đó tại đây" :-)
• đơn vị kiểm tra tài liệu hiệu quả (sự hiểu biết của bạn) về hành vi của mã của bạn
• kiểm tra đơn vị buộc bạn phải đánh giá lại các lựa chọn thiết kế của mình, điều này dẫn đến thiết kế đơn giản hơn, gọn gàng hơn

Lần lượt, các khung kiểm tra đơn vị, giúp bạn dễ dàng viết và chạy các bài kiểm tra của mình.

Tôi chưa bao giờ được dạy kiểm tra đơn vị tại trường đại học, và tôi phải mất một thời gian để "có được" nó. Tôi đã đọc về nó, đã đi "ah, phải, thử nghiệm tự động, điều đó có thể tuyệt vời tôi đoán", và sau đó tôi quên nó.

Phải mất khá nhiều thời gian trước khi tôi thực sự tìm ra vấn đề: Giả sử bạn đang làm việc trên một hệ thống lớn và bạn viết một mô-đun nhỏ. Nó biên dịch, bạn đặt nó qua các bước của nó, nó hoạt động rất tốt, bạn chuyển sang nhiệm vụ tiếp theo. Chín tháng sau và hai phiên bản sau đó có người khác thay đổi một phần dường như không liên quan đến chương trình, và nó phá vỡ mô-đun. Tệ hơn, họ kiểm tra các thay đổi của họ và mã của họ hoạt động, nhưng họ không kiểm tra mô-đun của bạn; địa ngục, họ thậm chí có thể không biết mô-đun của bạn tồn tại .

Và bây giờ bạn đã có một vấn đề: mã bị hỏng nằm trong thân cây và thậm chí không ai biết. Trường hợp tốt nhất là một người kiểm tra nội bộ tìm thấy nó trước khi bạn gửi, nhưng sửa mã mà muộn trong trò chơi là tốn kém. Và nếu không có người thử nghiệm nội bộ nào tìm thấy nó ... tốt, điều đó thực sự có thể rất tốn kém.

Giải pháp là kiểm tra đơn vị. Họ sẽ gặp vấn đề khi bạn viết mã - điều đó tốt - nhưng bạn có thể đã làm điều đó bằng tay. Phần thưởng thực sự là họ sẽ gặp vấn đề trong chín tháng khi bạn đang làm việc trong một dự án hoàn toàn khác, nhưng một thực tập sinh mùa hè nghĩ rằng nó sẽ trông gọn gàng hơn nếu các tham số đó theo thứ tự bảng chữ cái - và sau đó là bài kiểm tra đơn vị bạn đã viết lại cách không thành công và ai đó sẽ ném mọi thứ vào thực tập cho đến khi anh ta thay đổi thứ tự tham số trở lại. Đó là "lý do" của các bài kiểm tra đơn vị. :-)

Phát hiện ra những ưu điểm triết học của thử nghiệm đơn vị và TDD ở đây là một vài trong số những quan sát "bóng đèn" quan trọng của tôi, điều đó đưa tôi đến những bước đầu tiên dự kiến ​​trên con đường đến giác ngộ TDD (không có tin tức gốc hoặc nhất thiết) ...

1. TDD KHÔNG có nghĩa là viết gấp đôi số lượng mã. Mã kiểm tra thường khá nhanh và không đau để viết và là một phần quan trọng trong quá trình thiết kế của bạn và rất quan trọng.

2. TDD giúp bạn nhận ra khi nào nên ngừng mã hóa! Các bài kiểm tra của bạn cho bạn sự tự tin rằng bạn đã làm đủ cho đến bây giờ và có thể ngừng điều chỉnh và chuyển sang điều tiếp theo.

3. Các thử nghiệm và mã làm việc cùng nhau để đạt được mã tốt hơn. Mã của bạn có thể là xấu / lỗi. KIỂM TRA của bạn có thể là xấu / lỗi. Trong TDD, bạn đang giao dịch với khả năng BÓNG bị lỗi / lỗi khá thấp. Thường thì đó là bài kiểm tra cần sửa nhưng đó vẫn là một kết quả tốt.

4. TDD giúp chống táo bón mã hóa. Bạn có biết rằng cảm giác rằng bạn có quá nhiều thứ để làm mà bạn hầu như không biết bắt đầu từ đâu? Đó là chiều thứ sáu, nếu bạn chần chừ thêm vài giờ nữa ... TDD cho phép bạn giải quyết rất nhanh những gì bạn nghĩ bạn cần làm và khiến mã hóa của bạn chuyển động nhanh chóng. Ngoài ra, giống như chuột thí nghiệm, tôi nghĩ tất cả chúng ta đều phản ứng với ánh sáng xanh lớn đó và làm việc chăm chỉ hơn để nhìn thấy nó một lần nữa!

5. Trong một mạch tương tự, các loại thiết kế này có thể XEM những gì họ đang làm việc. Họ có thể đi lang thang để uống nước trái cây / thuốc lá / iphone và quay lại màn hình ngay lập tức cung cấp cho họ một gợi ý trực quan về nơi họ đến. TDD cho chúng ta một cái gì đó tương tự. Dễ dàng hơn để thấy nơi chúng ta đã đến khi cuộc sống can thiệp ...

6. Tôi nghĩ rằng chính Fowler đã nói: "Các bài kiểm tra không hoàn hảo, chạy thường xuyên, tốt hơn nhiều so với các bài kiểm tra hoàn hảo không bao giờ được viết". Tôi diễn giải điều này như cho phép tôi viết các bài kiểm tra trong đó tôi nghĩ chúng sẽ hữu ích nhất ngay cả khi phần còn lại của phạm vi bảo hiểm mã của tôi không đầy đủ.

7. TDD giúp tất cả các cách đáng ngạc nhiên xuống dòng. Các bài kiểm tra đơn vị tốt có thể giúp ghi lại những gì cần phải làm, chúng có thể giúp bạn di chuyển mã từ dự án này sang dự án khác và mang lại cho bạn cảm giác vượt trội không đáng có so với các đồng nghiệp không thử nghiệm của bạn :)

Bài trình bày này là một giới thiệu tuyệt vời cho tất cả các thử nghiệm lòng tốt ngon.

Tôi muốn giới thiệu cuốn sách Các mẫu thử nghiệm xUnit của Gerard Meszaros. Nó lớn nhưng là một tài nguyên tuyệt vời về thử nghiệm đơn vị. Đây là một liên kết đến trang web của anh ấy, nơi anh ấy thảo luận về những điều cơ bản của thử nghiệm đơn vị. http://xunitpotypes.com/XUnitBasics.html

Tôi sử dụng các bài kiểm tra đơn vị để tiết kiệm thời gian.

Khi xây dựng chức năng kiểm tra logic nghiệp vụ (hoặc truy cập dữ liệu) thường có thể liên quan đến việc nhập nội dung vào nhiều màn hình có thể hoặc chưa thể kết thúc. Tự động hóa các bài kiểm tra này tiết kiệm thời gian.

Đối với tôi kiểm tra đơn vị là một loại khai thác kiểm tra mô-đun. Thường có ít nhất một bài kiểm tra cho mỗi chức năng công cộng. Tôi viết các bài kiểm tra bổ sung để bao gồm các hành vi khác nhau.

Tất cả các trường hợp đặc biệt mà bạn nghĩ đến khi phát triển mã có thể được ghi lại trong mã trong các bài kiểm tra đơn vị. Các bài kiểm tra đơn vị cũng trở thành một nguồn ví dụ về cách sử dụng mã.

Tôi nhanh hơn rất nhiều khi phát hiện ra rằng mã mới của tôi phá vỡ thứ gì đó trong các bài kiểm tra đơn vị của tôi sau đó để kiểm tra mã và để một số nhà phát triển front-end tìm thấy một vấn đề.

Để kiểm tra truy cập dữ liệu, tôi cố gắng viết các bài kiểm tra không có thay đổi hoặc tự dọn sạch.

Các bài kiểm tra đơn vị sẽ không thể giải quyết tất cả các yêu cầu kiểm tra. Họ sẽ có thể tiết kiệm thời gian phát triển và kiểm tra các phần cốt lõi của ứng dụng.

Đây là quan điểm của tôi về nó. Tôi muốn nói kiểm thử đơn vị là thực hành viết kiểm thử phần mềm để xác minh rằng phần mềm thực sự của bạn làm đúng như ý nghĩa của nó. Điều này bắt đầu với jUnit trong thế giới Java và đã trở thành một cách thực hành tốt nhất trong PHP cũng như với SimpleTest và phpUnit . Đó là một thực tiễn cốt lõi của Lập trình cực đoan và giúp bạn chắc chắn rằng phần mềm của bạn vẫn hoạt động như dự định sau khi chỉnh sửa. Nếu bạn có đủ phạm vi kiểm tra, bạn có thể thực hiện tái cấu trúc lớn, sửa lỗi hoặc thêm các tính năng một cách nhanh chóng mà không sợ phải giới thiệu các vấn đề khác.

Nó hiệu quả nhất khi tất cả các bài kiểm tra đơn vị có thể được chạy tự động.

Kiểm thử đơn vị thường liên quan đến phát triển OO. Ý tưởng cơ bản là tạo ra một kịch bản thiết lập môi trường cho mã của bạn và sau đó thực hiện nó; bạn viết các xác nhận, chỉ định đầu ra dự định mà bạn sẽ nhận được và sau đó thực thi tập lệnh thử nghiệm của mình bằng cách sử dụng một khung như đã đề cập ở trên.

Khung sẽ chạy tất cả các thử nghiệm đối với mã của bạn và sau đó báo cáo lại thành công hay thất bại của mỗi thử nghiệm. phpUnit được chạy từ dòng lệnh Linux theo mặc định, mặc dù có sẵn các giao diện HTTP cho nó. SimpleTest dựa trên web và dễ dàng hơn nhiều để khởi động và chạy, IMO. Kết hợp với xDebug, phpUnit có thể cung cấp cho bạn số liệu thống kê tự động về phạm vi bảo hiểm mã mà một số người thấy rất hữu ích.

Một số nhóm viết các hook từ kho lưu trữ lật đổ của chúng để các bài kiểm tra đơn vị được chạy tự động bất cứ khi nào bạn cam kết thay đổi.

Đó là cách tốt để giữ các bài kiểm tra đơn vị của bạn trong cùng một kho lưu trữ với ứng dụng của bạn.

Các thư viện như NUnit , xUnit hoặc JUnit chỉ là bắt buộc nếu bạn muốn phát triển các dự án của mình bằng cách sử dụng phương pháp TDD phổ biến bởi Kent Beck:

Bạn có thể đọc Giới thiệu về Phát triển hướng thử nghiệm (TDD) hoặc cuốn sách Phát triển hướng thử nghiệm của Kent Beck : Ví dụ .

Sau đó, nếu bạn muốn chắc chắn rằng các bài kiểm tra của bạn bao gồm một phần "tốt" trong mã của bạn, bạn có thể sử dụng phần mềm như NCover , JCover , PartCover hoặc bất cứ điều gì. Họ sẽ cho bạn biết tỷ lệ phần trăm bảo hiểm của mã của bạn. Tùy thuộc vào mức độ bạn thành thạo tại TDD, bạn sẽ biết nếu bạn đã thực hành nó đủ tốt :)

Kiểm thử đơn vị là kiểm tra một đơn vị mã (ví dụ: một hàm duy nhất) mà không cần cơ sở hạ tầng mà đơn vị mã đó dựa vào. tức là kiểm tra nó trong sự cô lập.

Ví dụ, nếu chức năng mà bạn đang kiểm tra kết nối với cơ sở dữ liệu và thực hiện cập nhật, trong thử nghiệm đơn vị, bạn có thể không muốn thực hiện cập nhật đó. Bạn sẽ làm nếu đó là một bài kiểm tra tích hợp nhưng trong trường hợp này thì không.

Vì vậy, kiểm tra đơn vị sẽ thực hiện chức năng kèm theo trong "chức năng" mà bạn đang kiểm tra mà không có tác dụng phụ của cập nhật cơ sở dữ liệu.

Nói rằng hàm của bạn đã lấy một số số từ cơ sở dữ liệu và sau đó thực hiện phép tính độ lệch chuẩn. Bạn đang cố gắng thử nghiệm gì ở đây? Độ lệch chuẩn được tính toán chính xác hay dữ liệu được trả về từ cơ sở dữ liệu?

Trong một bài kiểm tra đơn vị, bạn chỉ muốn kiểm tra độ lệch chuẩn được tính toán chính xác. Trong thử nghiệm tích hợp, bạn muốn kiểm tra tính toán độ lệch chuẩn và truy xuất cơ sở dữ liệu.

Kiểm thử đơn vị là về viết mã kiểm tra mã ứng dụng của bạn.

Phần Đơn vị của tên nói về ý định kiểm tra các đơn vị mã nhỏ (ví dụ một phương thức) tại một thời điểm.

xUnit sẵn sàng trợ giúp cho thử nghiệm này - chúng là các khung hỗ trợ cho việc này. Một phần trong số đó là các bài kiểm tra tự động cho bạn biết bài kiểm tra nào thất bại và bài kiểm tra nào vượt qua.

Họ cũng có các phương tiện để thiết lập mã chung mà bạn cần trong mỗi bài kiểm tra trước khi xử lý và xé nó khi tất cả các bài kiểm tra đã kết thúc.

Bạn có thể có một bài kiểm tra để kiểm tra xem một ngoại lệ dự kiến ​​đã được ném, mà không phải tự viết toàn bộ khối thử bắt.

Tôi nghĩ rằng điểm mà bạn không hiểu là các khung kiểm tra đơn vị như NUnit (và tương tự) sẽ giúp bạn tự động hóa các bài kiểm tra cỡ nhỏ đến trung bình. Thông thường, bạn có thể chạy thử nghiệm trong GUI ( ví dụ như trường hợp với NUnit ) bằng cách nhấp vào nút và sau đó - hy vọng - thấy thanh tiến trình giữ màu xanh lá cây. Nếu nó chuyển sang màu đỏ, khung cho bạn thấy thử nghiệm nào thất bại và chính xác là sai. Trong một thử nghiệm đơn vị bình thường, bạn thường sử dụng các xác nhận, ví dụ Assert.AreEqual(expectedValue, actualValue, "some description")- vì vậy nếu hai giá trị không bằng nhau, bạn sẽ thấy một lỗi có nội dung "một số mô tả: dự kiến ​​<kỳ vọng> nhưng là <factValue>".

Vì vậy, như một thử nghiệm đơn vị kết luận sẽ làm cho thử nghiệm nhanh hơn và thoải mái hơn rất nhiều cho các nhà phát triển. Bạn có thể chạy tất cả các bài kiểm tra đơn vị trước khi cam kết mã mới để không phá vỡ quy trình xây dựng của các nhà phát triển khác trong cùng một dự án.

Sử dụng Testivus . Tất cả những gì bạn cần biết là ở ngay đó :)

Kiểm thử đơn vị là một thực tiễn để đảm bảo rằng chức năng hoặc mô-đun mà bạn sẽ triển khai sẽ hoạt động như mong đợi (yêu cầu) và cũng để đảm bảo cách thức hoạt động trong các tình huống như điều kiện biên và đầu vào không hợp lệ.

xUnit , NUnit , mbUnit , v.v. là những công cụ giúp bạn viết bài kiểm tra.

Kiểm tra hướng phát triển đã được thực hiện qua thuật ngữ Đơn vị kiểm tra. Là một bộ đếm thời gian cũ, tôi sẽ đề cập đến định nghĩa chung hơn về nó.

Kiểm thử đơn vị cũng có nghĩa là kiểm tra một thành phần duy nhất trong một hệ thống lớn hơn. Thành phần đơn lẻ này có thể là một thư viện dll, exe, class, v.v. Nó thậm chí có thể là một hệ thống duy nhất trong một ứng dụng đa hệ thống. Vì vậy, cuối cùng, Unit Test kết thúc là thử nghiệm bất cứ thứ gì bạn muốn gọi là một phần của một hệ thống lớn hơn.

Sau đó, bạn sẽ chuyển sang kiểm tra tích hợp hoặc hệ thống bằng cách kiểm tra cách tất cả các thành phần hoạt động cùng nhau.

Trước hết, cho dù nói về thử nghiệm Đơn vị hoặc bất kỳ loại thử nghiệm tự động nào khác (Tích hợp, Tải, kiểm tra giao diện người dùng, v.v.), điểm khác biệt chính so với những gì bạn đề xuất là nó tự động, có thể lặp lại và không yêu cầu bất kỳ nguồn nhân lực nào được tiêu thụ (= không ai phải thực hiện các bài kiểm tra, họ thường chạy chỉ bằng cách nhấn nút).

Tôi đã đi đến một bài thuyết trình về thử nghiệm đơn vị tại FoxForward 2007 và được bảo không bao giờ thử nghiệm đơn vị bất cứ thứ gì hoạt động với dữ liệu. Xét cho cùng, nếu bạn kiểm tra dữ liệu trực tiếp, kết quả không thể đoán trước và nếu bạn không kiểm tra dữ liệu trực tiếp, thì bạn không thực sự kiểm tra mã bạn đã viết. Thật không may, đó là hầu hết các mã hóa tôi làm những ngày này. :-)

Gần đây tôi đã chụp tại TDD khi tôi đang viết một thói quen để lưu và khôi phục cài đặt. Đầu tiên, tôi xác minh rằng tôi có thể tạo đối tượng lưu trữ. Sau đó, nó có phương thức tôi cần gọi. Sau đó, tôi có thể gọi nó. Sau đó, tôi có thể vượt qua nó các tham số. Sau đó, tôi có thể vượt qua nó các thông số cụ thể. Và như vậy, cho đến khi tôi cuối cùng đã xác minh rằng nó sẽ lưu cài đặt đã chỉ định, cho phép tôi thay đổi nó, và sau đó khôi phục nó, cho một số cú pháp khác nhau.

Tôi đã không đi đến cuối cùng, bởi vì tôi cần-thói quen-bây giờ-chết tiệt, nhưng đó là một bài tập tốt.

Bạn sẽ làm gì nếu bạn bị cho một đống rác rưởi và dường như bạn bị mắc kẹt trong trạng thái dọn dẹp vĩnh viễn mà bạn biết với việc thêm bất kỳ tính năng hoặc mã mới nào có thể phá vỡ bộ hiện tại vì phần mềm hiện tại giống như một ngôi nhà của thẻ?

Làm thế nào chúng ta có thể làm thử nghiệm đơn vị sau đó?

Bạn bắt đầu nhỏ. Dự án tôi vừa tham gia không có thử nghiệm đơn vị cho đến vài tháng trước. Khi phạm vi bảo hiểm thấp, chúng tôi chỉ cần chọn một tệp không có phạm vi bảo hiểm và nhấp vào "thêm kiểm tra".

Ngay bây giờ, chúng tôi lên tới hơn 40% và chúng tôi đã quản lý để hái hầu hết các loại trái cây treo thấp.

(Phần tốt nhất là ngay cả ở mức độ bao phủ thấp này, chúng tôi đã gặp phải nhiều trường hợp mã làm sai và thử nghiệm đã bắt được nó. Đó là một động lực rất lớn để thúc đẩy mọi người thêm thử nghiệm.)

Điều này trả lời tại sao bạn nên làm thử nghiệm đơn vị.

3 video dưới đây bao gồm kiểm tra đơn vị trong javascript nhưng các nguyên tắc chung áp dụng trên hầu hết các ngôn ngữ.

Kiểm tra đơn vị: Phút ngay bây giờ sẽ tiết kiệm giờ sau - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

Kiểm tra đơn vị JS (rất tốt) - https://www.youtube.com/watch?v=-IYqgx8JxlU

Viết JavaScript có thể kiểm tra - https://www.youtube.com/watch?v=OzjogCFO4Zo

Bây giờ tôi chỉ tìm hiểu về chủ đề này nên tôi có thể không đúng 100% và có nhiều điều hơn so với những gì tôi mô tả ở đây nhưng hiểu biết cơ bản của tôi về kiểm tra đơn vị là bạn viết một số mã kiểm tra (được tách biệt với bạn mã chính) gọi một hàm trong mã chính của bạn bằng đầu vào (đối số) mà hàm yêu cầu và sau đó mã sẽ kiểm tra xem nó có nhận được giá trị trả về hợp lệ không. Nếu nó lấy lại giá trị hợp lệ, khung kiểm tra đơn vị mà bạn đang sử dụng để chạy thử nghiệm sẽ hiển thị đèn xanh (tất cả đều tốt) nếu giá trị không hợp lệ, bạn sẽ có đèn đỏ và sau đó bạn có thể khắc phục sự cố ngay trước khi bạn phát hành mã mới để sản xuất, mà không cần kiểm tra, bạn thực sự có thể không bắt lỗi.

Vì vậy, bạn viết các bài kiểm tra cho bạn mã hiện tại và tạo mã để nó vượt qua bài kiểm tra. Nhiều tháng sau, bạn hoặc người khác cần sửa đổi hàm trong mã chính của bạn, bởi vì trước đó bạn đã viết mã kiểm tra cho hàm đó, bây giờ bạn chạy lại và kiểm tra có thể thất bại vì bộ mã hóa đã đưa ra lỗi logic trong hàm hoặc trả về một cái gì đó hoàn toàn khác với những gì chức năng được cho là trả lại. Một lần nữa, không có kiểm tra tại chỗ, lỗi có thể khó theo dõi vì nó cũng có thể ảnh hưởng đến các mã khác và sẽ không được chú ý.

Ngoài ra, thực tế là bạn có một chương trình máy tính chạy qua mã của bạn và kiểm tra nó thay vì bạn tự làm nó trong trang trình duyệt theo trang giúp tiết kiệm thời gian (kiểm tra đơn vị cho javascript). Giả sử bạn sửa đổi một chức năng được sử dụng bởi một số tập lệnh trên trang web và nó hoạt động tốt và tốt cho mục đích mới của nó. Tuy nhiên, chúng ta cũng nói đối với các đối số vì có một chức năng khác mà bạn có ở một nơi khác trong mã của bạn phụ thuộc vào chức năng mới được sửa đổi đó để nó hoạt động đúng. Chức năng phụ thuộc này hiện có thể ngừng hoạt động do những thay đổi bạn đã thực hiện cho chức năng đầu tiên, tuy nhiên không có kiểm tra tại chỗ được chạy tự động bởi máy tính của bạn, bạn sẽ không nhận thấy rằng có vấn đề với chức năng đó cho đến khi nó thực sự được thực thi và bạn'

Để nhắc lại, có các bài kiểm tra được chạy trong khi phát triển ứng dụng của bạn sẽ gặp các loại vấn đề này khi bạn đang mã hóa. Không có các bài kiểm tra tại chỗ, bạn phải tự kiểm tra toàn bộ ứng dụng của mình và thậm chí sau đó có thể khó phát hiện ra lỗi, bạn ngây thơ gửi nó vào sản xuất và sau một thời gian, một người dùng tốt bụng sẽ gửi cho bạn một báo cáo lỗi (mà sẽ không tốt như thông báo lỗi của bạn trong khung kiểm tra).

Thật khó hiểu khi lần đầu tiên bạn nghe về chủ đề này và bạn tự nghĩ, có phải tôi chưa kiểm tra mã của mình? Và mã mà bạn đã viết đang hoạt động giống như được cho là đã có, "tại sao tôi cần một khung công tác khác?" ... Có bạn đang kiểm tra mã của mình nhưng máy tính sẽ hoạt động tốt hơn. Bạn chỉ cần viết các bài kiểm tra đủ tốt cho một chức năng / đơn vị mã một lần và phần còn lại được chăm sóc cho bạn bởi cpu hùng mạnh thay vì bạn phải kiểm tra thủ công rằng tất cả mã của bạn vẫn hoạt động khi bạn thay đổi ma cua ban.

Ngoài ra, bạn không phải kiểm tra đơn vị mã của mình nếu bạn không muốn nhưng nó sẽ thành công khi dự án / cơ sở mã của bạn bắt đầu phát triển lớn hơn khi cơ hội giới thiệu lỗi tăng lên.

Kiểm thử đơn vị và TDD nói chung cho phép bạn có chu kỳ phản hồi ngắn hơn về phần mềm bạn đang viết. Thay vì có một giai đoạn thử nghiệm lớn vào cuối quá trình thực hiện, bạn tăng dần kiểm tra mọi thứ bạn viết. Điều này làm tăng chất lượng mã rất nhiều, như bạn thấy ngay lập tức, nơi bạn có thể có lỗi.