Tôi vừa tốt nghiệp với bằng về CS và hiện tại tôi có một công việc là Nhà phát triển Junior .NET (C #, ASP.NET và các mẫu web). Quay lại khi tôi còn ở trường đại học, chủ đề kiểm tra đơn vị đã được đề cập nhưng tôi chưa bao giờ thực sự thấy được lợi ích của nó. Tôi hiểu những gì nó phải làm, cụ thể là, xác định xem một khối mã có phù hợp để sử dụng hay không. Tuy nhiên, tôi chưa bao giờ thực sự phải viết một bài kiểm tra đơn vị trước đây, tôi cũng không bao giờ cảm thấy cần thiết.

Như tôi đã đề cập, tôi thường phát triển với các mẫu web ASP.NET và gần đây tôi đã nghĩ đến việc viết một số bài kiểm tra đơn vị. Nhưng tôi đã có một vài câu hỏi về điều này.

Tôi đã đọc rằng kiểm tra đơn vị thường xảy ra thông qua việc viết "giả". Trong khi tôi hiểu khái niệm này, tôi dường như không thể hiểu làm thế nào tôi phải viết giả cho các trang web hoàn toàn năng động và hầu hết mọi thứ phụ thuộc vào dữ liệu đến từ cơ sở dữ liệu. Ví dụ: Tôi sử dụng rất nhiều bộ lặp có các sự kiện ItemDataBound, v.v. (một lần nữa tùy thuộc vào dữ liệu là "không xác định").

Vì vậy, câu hỏi số 1: Việc viết các bài kiểm tra đơn vị cho web ASP.NET có phải là một việc được thực hiện thường xuyên không và nếu đó là: làm thế nào để tôi giải quyết vấn đề "môi trường động"?

Khi tôi đang phát triển, tôi gặp rất nhiều lỗi và thử. Điều đó không có nghĩa là tôi không biết tôi đang làm gì, nhưng ý tôi là tôi thường viết một số mã, nhấn Ctrl F5và xem điều gì sẽ xảy ra. Mặc dù cách tiếp cận này thực hiện công việc hầu hết thời gian, đôi khi tôi có cảm giác rằng tôi hơi khó hiểu (vì kinh nghiệm ít ỏi của tôi). Đôi khi tôi cũng lãng phí rất nhiều thời gian như thế này.

Vì vậy, câu hỏi số 2: Các bạn có khuyên tôi nên bắt đầu viết bài kiểm tra đơn vị không? Tôi nghĩ rằng nó có thể giúp tôi trong việc thực hiện thực tế, nhưng sau đó một lần nữa tôi cảm thấy như nó có thể làm tôi chậm lại.

Theo ý kiến ​​của tôi: có họ là có, và có bạn nên.

1. Họ cho bạn niềm tin vào những thay đổi bạn thực hiện (mọi thứ khác vẫn đang hoạt động). Sự tự tin này là những gì bạn cần để tạo ra mã, nếu không bạn có thể sợ thay đổi mọi thứ.

2. Họ làm cho mã của bạn tốt hơn; hầu hết các lỗi đơn giản được bắt gặp sớm với các bài kiểm tra đơn vị. Bắt lỗi sớm và sửa chúng luôn rẻ hơn sửa lỗi sau, ví dụ, khi ứng dụng được sản xuất.

3. Chúng đóng vai trò là tài liệu cho các nhà phát triển khác về cách mã của bạn hoạt động và cách sử dụng nó.

Vấn đề đầu tiên bạn gặp phải là bản thân ASP.NET không giúp bạn viết bài kiểm tra đơn vị, thực tế nó hoạt động chống lại bạn. Nếu bạn có bất kỳ sự lựa chọn nào, hãy bắt đầu sử dụng ASP.NET MVC , được tạo ra với mục đích kiểm tra đơn vị. Nếu bạn không thể sử dụng ASP.NET MVC, bạn nên sử dụng mẫu MVP trong ASP.NET để ít nhất bạn có thể kiểm tra logic của mình một cách dễ dàng.

Bên cạnh đó, bạn chỉ cần thành thạo trong việc viết bài kiểm tra đơn vị. Nếu bạn thực hành TDD, mã của bạn được tạo ra có thể kiểm tra được bằng cách nói khác, hay và sạch sẽ.

Tôi sẽ khuyên bạn thực hành, và cặp chương trình. Trong khi đang đọc:

• Phát triển phần mềm, nguyên tắc, mô hình và thực tiễn của Agile [Bìa cứng]
• Mẫu thiết kế đầu tiên
• GOF Thiết kế mẫu kinh thánh
• Giới thiệu đầu tiên của Roy osherove về thử nghiệm đơn vị
• mẫu thử nghiệm kinh thánh

Hoặc, để có cái nhìn tổng quan đầu tiên:

• CHẤT RẮN
• Các mẫu thử nghiệm Xunit

Không.

Khái niệm đằng sau các bài kiểm tra đơn vị dựa trên một tiền đề đã được biết là sai từ trước khi thử nghiệm đơn vị được phát minh: ý tưởng rằng các bài kiểm tra có thể chứng minh rằng mã của bạn là chính xác.

Có rất nhiều bài kiểm tra mà tất cả đều vượt qua chứng minh một điều và chỉ một điều duy nhất: rằng bạn có rất nhiều bài kiểm tra mà tất cả đều vượt qua. Nó không chứng minh rằng những gì các bài kiểm tra đang kiểm tra phù hợp với thông số kỹ thuật. Nó không chứng minh rằng mã của bạn không có lỗi mà bạn chưa bao giờ xem xét khi bạn viết bài kiểm tra. (Và những điều bạn nghĩ để kiểm tra là những vấn đề có thể xảy ra mà bạn đang tập trung vào, vì vậy dù sao bạn cũng có thể đã hiểu đúng!) không có lỗi (Làm theo câu hỏi cuối cùng để đưa ra kết luận hợp lý và cuối cùng bạn sẽ có rùa .)

Djikstra đã bỏ qua khái niệm về cách kiểm tra bằng chứng chính xác từ năm 1988, và những gì ông viết vẫn còn nguyên giá trị cho đến ngày nay:

Bây giờ là hai thập kỷ kể từ khi chỉ ra rằng thử nghiệm chương trình có thể chứng minh một cách thuyết phục sự hiện diện của lỗi, nhưng không bao giờ có thể chứng minh sự vắng mặt của chúng. Sau khi trích dẫn lời nhận xét được công bố rộng rãi này, kỹ sư phần mềm trở lại trật tự trong ngày và tiếp tục hoàn thiện các chiến lược thử nghiệm của mình, giống như nhà giả kim của yore, người tiếp tục tinh chỉnh các tinh chế chrysocosmic của mình.

Vấn đề khác với kiểm thử đơn vị là nó tạo ra sự kết hợp chặt chẽ giữa mã của bạn và bộ kiểm thử. Khi bạn thay đổi mã, bạn sẽ mong đợi một số lỗi xuất hiện sẽ phá vỡ một số thử nghiệm. Nhưng nếu bạn đang thay đổi mã vì bản thân các yêu cầu đã thay đổi, bạn sẽ nhận được rất nhiều bài kiểm tra thất bại và bạn sẽ phải tự mình kiểm tra từng phần và quyết định xem bài kiểm tra có còn hiệu lực hay không. (Và nó cũng có thể, mặc dù ít phổ biến hơn, đó là một thử nghiệm hiện có mà nên là không hợp lệ vẫn sẽ vượt qua vì bạn quên thay đổi một cái gì đó cần phải được thay đổi.)

Kiểm thử đơn vị chỉ là mới nhất trong một chuỗi dài các nhà phát triển hứa hẹn sẽ giúp viết mã làm việc dễ dàng hơn mà không thực sự là một lập trình viên giỏi. Không ai trong số họ từng quản lý để thực hiện lời hứa của họ, và điều này cũng không. Đơn giản là không có phím tắt để thực sự biết cách viết mã làm việc .

Có một số báo cáo về thử nghiệm tự động thực sự hữu ích trong trường hợp độ ổn định và độ tin cậy là rất quan trọng. Ví dụ, dự án cơ sở dữ liệu SQLite. Nhưng những gì nó cần để đạt được mức độ tin cậy của chúng là rất kinh tế đối với hầu hết các dự án: tỷ lệ mã thử nghiệm-thực tế-SQLite gần như 1200: 1. Hầu hết các dự án không đủ khả năng đó và dù sao cũng không cần nó.

Nếu bạn đã từng thấy lợi ích khi viết một phương pháp chính để kiểm tra một số đoạn mã nhỏ cho trường học, thì kiểm thử đơn vị là phiên bản chuyên nghiệp / doanh nghiệp của cùng một hoạt động đó.

Ngoài ra, hãy tưởng tượng chi phí xây dựng mã, khởi động máy chủ web cục bộ của bạn, duyệt đến trang được đề cập, nhập dữ liệu hoặc đặt đầu vào cho hạt giống thử nghiệm thích hợp, gửi biểu mẫu và phân tích kết quả ... so với xây dựng và nhấn nút chạy nUnit.

Đây cũng là một hình ảnh vui nhộn ...

Tôi tìm thấy hình ảnh này ở đây:
http://www.howtogeek.com/102420/geek-versus-non-geek-when-doing-repetitive-t task-funny-chart /

Kiểm tra đơn vị có một cái gì đó bí ẩn về nó những ngày này. Mọi người coi nó như thể phạm vi kiểm tra 100% là một chén thánh và như thể kiểm thử đơn vị là một cách phát triển phần mềm.

Họ đang thiếu điểm.

Kiểm tra đơn vị không phải là câu trả lời. Kiểm tra là.

Bây giờ, bất cứ khi nào cuộc thảo luận này xuất hiện, một người nào đó (thường là tôi) sẽ nói ra câu nói của Dijkstra: "Thử nghiệm chương trình có thể chứng minh sự hiện diện của bọ, nhưng không bao giờ chứng minh sự vắng mặt của chúng." Dijkstra đã đúng: kiểm tra là không đủ để chứng minh rằng phần mềm hoạt động như dự định. Nhưng nó là cần thiết : ở một mức độ nào đó, phải có khả năng chứng minh rằng phần mềm đang làm những gì bạn muốn nó.

Nhiều người kiểm tra bằng tay. Ngay cả những người đam mê TDD trung thành cũng sẽ thực hiện kiểm tra thủ công, mặc dù đôi khi họ sẽ không thừa nhận điều đó. Không thể tránh khỏi: ngay trước khi bạn vào phòng hội thảo để giới thiệu phần mềm của bạn với khách hàng / sếp / nhà đầu tư / v.v., bạn sẽ chạy qua nó bằng tay để đảm bảo nó sẽ hoạt động. Không có gì sai với điều đó, và trên thực tế sẽ thật điên rồ khi chỉ mong mọi thứ diễn ra suôn sẻ mà không phải chạy bằng tay - nghĩa là thử nghiệm nó - ngay cả khi bạn có phạm vi kiểm tra đơn vị 100% và sự tự tin tối đa trong các bài kiểm tra của bạn .

Nhưng kiểm tra thủ công, mặc dù nó là cần thiết để xây dựng phần mềm, hiếm khi là đủ . Tại sao? Bởi vì kiểm tra thủ công là tẻ nhạt, tốn thời gian và được thực hiện bởi con người. Và con người nổi tiếng là tồi tệ khi thực hiện các nhiệm vụ tẻ nhạt và tốn thời gian: họ tránh thực hiện chúng bất cứ khi nào có thể và họ thường không làm tốt khi họ bị ép buộc.

Máy móc , mặt khác, là tuyệt vời để thực hiện các nhiệm vụ tẻ nhạt và tốn thời gian. Rốt cuộc, đó là thứ mà máy tính được phát minh ra.

Vì vậy, kiểm tra là rất quan trọng và kiểm tra tự động là cách hợp lý duy nhất để đảm bảo rằng các kiểm tra của bạn được sử dụng một cách nhất quán. Và điều quan trọng là phải kiểm tra và kiểm tra lại, vì phần mềm được phát triển. Một câu trả lời khác ở đây lưu ý tầm quan trọng của kiểm tra hồi quy . Do sự phức tạp của các hệ thống phần mềm, những thay đổi dường như vô hại đối với một phần của hệ thống gây ra những thay đổi ngoài ý muốn (tức là lỗi) trong các phần khác của hệ thống. Bạn không thể khám phá những thay đổi ngoài ý muốn này mà không có một số hình thức kiểm tra. Và nếu bạn muốn có dữ liệu đáng tin cậy về các bài kiểm tra của mình, bạn phải thực hiện kiểm tra theo cách có hệ thống, có nghĩa là bạn phải có một số loại hệ thống kiểm tra tự động.

Tất cả những điều này có liên quan gì đến thử nghiệm đơn vị? Vâng, do bản chất của chúng, các bài kiểm tra đơn vị được điều hành bởi máy chứ không phải bởi con người. Do đó, nhiều người có ấn tượng sai lầm rằng thử nghiệm tự động bằng với thử nghiệm đơn vị . Nhưng điều đó không đúng: các bài kiểm tra đơn vị chỉ là các bài kiểm tra tự động nhỏ thêm .

Bây giờ, giá trị trong các thử nghiệm tự động nhỏ thêm là gì? Ưu điểm là họ kiểm tra các thành phần của một hệ thống phần mềm một cách riêng biệt , cho phép nhắm mục tiêu kiểm tra chính xác hơn và hỗ trợ gỡ lỗi . Nhưng thử nghiệm đơn vị về bản chất không có nghĩa là thử nghiệm chất lượng cao hơn . Nó thường dẫn đến các bài kiểm tra chất lượng cao hơn, do nó bao trùm phần mềm ở mức độ chi tiết tốt hơn. Nhưng có thể kiểm tra hoàn toàn hành vi của chỉ một hệ thống hoàn chỉnh chứ không phải các bộ phận tổng hợp của nó và vẫn kiểm tra kỹ lưỡng.

Nhưng ngay cả với phạm vi kiểm tra đơn vị 100%, một hệ thống vẫn có thể không được kiểm tra kỹ lưỡng. Bởi vì các thành phần riêng lẻ có thể hoạt động hoàn hảo trong sự cô lập, nhưng vẫn thất bại khi được sử dụng cùng nhau. Vì vậy, kiểm tra đơn vị, trong khi rất hữu ích, không đủ để đảm bảo rằng phần mềm hoạt động như mong đợi. Thật vậy, nhiều nhà phát triển bổ sung các bài kiểm tra đơn vị bằng các bài kiểm tra tích hợp tự động, kiểm tra chức năng tự động và kiểm tra thủ công.

Nếu bạn không thấy giá trị trong các bài kiểm tra đơn vị, có lẽ cách tốt nhất để bắt đầu là sử dụng một loại kiểm tra tự động khác. Trong môi trường web, sử dụng công cụ kiểm tra tự động hóa trình duyệt như Selenium thường sẽ mang lại một chiến thắng lớn cho khoản đầu tư tương đối nhỏ. Khi bạn đã nhúng ngón chân vào nước, bạn sẽ dễ dàng nhận thấy các bài kiểm tra tự động hữu ích như thế nào. Và một khi bạn có các bài kiểm tra tự động, kiểm tra đơn vị có ý nghĩa hơn nhiều, vì nó cung cấp khả năng quay vòng nhanh hơn so với các bài kiểm tra tích hợp hoặc kết thúc lớn, vì bạn có thể nhắm mục tiêu các bài kiểm tra tại thành phần mà bạn hiện đang làm việc.

TL; DR: đừng lo lắng về thử nghiệm đơn vị . Chỉ cần lo lắng về việc kiểm tra phần mềm của bạn đầu tiên.

Nó phụ thuộc

Đây là một câu trả lời mà bạn sẽ thấy rất nhiều khi nói đến phát triển phần mềm, nhưng tính hữu ích của các bài kiểm tra đơn vị thực sự phụ thuộc vào mức độ chúng được viết. Một số lượng thử nghiệm đơn vị danh nghĩa kiểm tra chức năng của ứng dụng để kiểm tra hồi quy có thể khá hữu ích; tuy nhiên, rất nhiều thử nghiệm đơn giản kiểm tra lợi nhuận của các hàm có thể khá vô dụng và mang lại cảm giác an toàn sai lầm vì ứng dụng "có rất nhiều thử nghiệm đơn vị."

Hơn nữa, thời gian của bạn là một nhà phát triển là có giá trị và thời gian viết bài kiểm tra đơn vị là thời gian không dành để viết các tính năng mới. Một lần nữa, điều này không có nghĩa là bạn không nên viết bài kiểm tra đơn vị, nhưng mỗi chức năng công khai có cần kiểm tra đơn vị không? Tôi sẽ gửi rằng câu trả lời là không. Mã đang thực hiện xác nhận nhập liệu của người dùng có cần kiểm tra đơn vị không? Rất có thể vì đây là một điểm thất bại phổ biến trong các ứng dụng.

Đây là một trong những lĩnh vực mà kinh nghiệm phát huy tác dụng, theo thời gian bạn sẽ nhận ra các phần của ứng dụng có thể được hưởng lợi từ bài kiểm tra đơn vị, nhưng sẽ mất một lúc trước khi bạn đạt đến điểm đó.

Các dự án được thực hiện cho các lớp học đại học khác rất nhiều so với các ứng dụng kinh doanh bạn sẽ viết trong công việc của mình. Sự khác biệt là tuổi thọ. Dự án đại học "sống" được bao lâu? Trong hầu hết các trường hợp, nó bắt đầu khi bạn viết dòng mã đầu tiên và kết thúc khi bạn nhận được dấu của mình. Bạn có thể nói rằng, hiệu quả là nó chỉ sống trong thời gian thực hiện. "Phát hành" thường bằng "cái chết" của nó.

Phần mềm được thực hiện cho doanh nghiệp vượt qua điểm phát hành của dự án đại học và tiếp tục sống miễn là doanh nghiệp cần nó. Mà là rất dài . Khi nói về tiền, không ai sẽ bỏ ra một xu hỏng để có "mã mát hơn và gọn gàng hơn". Nếu phần mềm được viết bằng C 25 năm trước vẫn hoạt động và đủ tốt (theo nhu cầu của chủ doanh nghiệp), bạn sẽ được yêu cầu duy trì phần mềm (thêm tính năng mới, cải thiện tính năng cũ - thay đổi mã nguồn ).

Chúng ta đến một điểm rất quan trọng - hồi quy . Tại nơi tôi làm việc, chúng tôi có hai đội duy trì hai ứng dụng; một, đã viết khoảng 5-6 năm trước với rất ít mã kiểm tra phạm vi *, và phiên bản thứ hai, phiên bản mới hơn của ứng dụng đầu tiên với bộ thử nghiệm đầy đủ (đơn vị, tích hợp và những thứ khác). Cả hai đội đều có người kiểm tra hướng dẫn sử dụng (con người). Bạn muốn biết mất bao lâu để giới thiệu một tính năng mới, khá cơ bản cho đội đầu tiên? 3 đến 4 tuần. Một nửa thời gian này là "kiểm tra xem mọi thứ khác có còn hoạt động không". Đây là thời gian bận rộn cho người kiểm tra thủ công. Điện thoại reo, mọi người bực mình, có gì đó lại hỏng. Đội thứ hai thường xử lý các vấn đề như vậy trong vòng chưa đầy 3 ngày.

Tôi không có nghĩa là các bài kiểm tra đơn vị làm cho mã của bạn dễ bị lỗi, chính xác hoặc các từ ưa thích khác mà bạn có thể đưa ra. Không phải họ làm cho lỗi biến mất một cách kỳ diệu. Nhưng khi kết hợp với các phương pháp kiểm thử phần mềm tự động khác, chúng làm cho các ứng dụng của bạn dễ bảo trì hơn nhiều so với các cách khác. Đây là một chiến thắng rất lớn.

Và cuối cùng nhưng không kém phần quan trọng, bình luận của Brian mà tôi nghĩ rằng vấn đề này:

(...) họ làm tăng sự tự tin của bạn (hoặc nên ...) rằng mã thực hiện những gì bạn đã thiết kế để làm và tiếp tục thực hiện vào ngày mai những gì nó làm hôm nay.

Bởi vì giữa ngày hôm nay và ngày mai, ai đó có thể thực hiện một thay đổi nhỏ sẽ khiến mã trình tạo báo cáo cực kỳ quan trọng bị sập. Các thử nghiệm đẩy tỷ lệ cược mà bạn sẽ tìm thấy điều này trước khi khách hàng của bạn làm một chút về phía bạn.

_{* Họ từ từ giới thiệu ngày càng nhiều thử nghiệm cho cơ sở mã của họ, nhưng tất cả chúng ta đều biết công cụ này thường trông như thế nào.}

đang viết các bài kiểm tra đơn vị cho các biểu mẫu web ASP.NET một cái gì đó được thực hiện thường xuyên và nếu đó là: làm thế nào để tôi giải quyết vấn đề "môi trường động"?

Nó không thường được thực hiện. Làm việc với các thành phần UI không phải là thử nghiệm đơn vị nào tốt, vì không có cách nào tuyệt vời để xác minh bằng lập trình rằng những thứ phù hợp kết thúc trên màn hình ở đúng nơi.

Các bạn có thể khuyên tôi nên bắt đầu viết bài kiểm tra đơn vị? Tôi nghĩ rằng nó có thể giúp tôi trong việc thực hiện thực tế, nhưng một lần nữa tôi cảm thấy như nó có thể làm tôi chậm lại.

Trường hợp áp dụng, có. Chúng có thể rất hữu ích trong việc xác minh các trường hợp cụ thể theo cách lặp lại. Chúng giúp hoạt động như 'ma sát' chống lại những thay đổi rắc rối và không an toàn khi bạn thực hiện các thay đổi tốt hơn.

Một điều cần lưu ý là họ thường sẽ làm bạn chậm lại.

Không sao đâu

Dành một chút thời gian bây giờ sẽ (nếu được thực hiện tốt) giúp bạn tiết kiệm thời gian trong tương lai vì chúng bắt được một số lỗi, ngăn ngừa sự tái phát của một số lỗi và cho phép bạn thoải mái hơn khi thực hiện các cải tiến khác trong mã để không bị mục nát.

Tôi vừa tốt nghiệp với bằng về CS và tôi hiện đang có một công việc là một nhà phát triển .NET cơ sở (trong C # và thường là ASP.NET, các mẫu web - không phải ASP.NET MVC). Quay lại khi tôi còn ở trường đại học, chủ đề kiểm tra đơn vị đã được đề cập, nhưng tôi chưa bao giờ thực sự thấy được lợi ích của nó.

Đó là bởi vì bạn không bao giờ lập trình lớn.

Tôi hiểu những gì nó phải làm -determine wether hoặc không phải là một khối mã> phù hợp để sử dụng - nhưng tôi chưa bao giờ thực sự phải viết một bài kiểm tra đơn vị trước đây. (cũng không bao giờ tôi cảm thấy cần phải ..)

Viết các bài kiểm tra đơn vị buộc mã của bạn phải tuân theo một cấu trúc tinh thần nhất định có thể kiểm tra được, được ghi chép tốt và đáng tin cậy. Nó nhiều hơn những gì bạn yêu cầu.

-Tôi đã đọc rằng kiểm tra đơn vị thường xảy ra thông qua việc viết "giả". Trong khi tôi hiểu khái niệm này, tôi dường như không thể tìm ra cách tôi nên viết giả cho các trang web hoàn toàn năng động và hầu hết mọi thứ phụ thuộc vào dữ liệu đến từ cơ sở dữ liệu.

giả định truy cập cơ sở dữ liệu với một lớp giả trả về các lớp mô hình chứa đầy dữ liệu được mã hóa, được xác định rõ. hoặc , điền vào cơ sở dữ liệu thử nghiệm với dữ liệu lịch thi đấu và làm việc từ đó.

-Có phải các bạn khuyên tôi nên bắt đầu viết bài kiểm tra đơn vị?

đồng ý luôn. Đọc "Phát triển hướng thử nghiệm" của Beck trước.

Tôi nghĩ rằng nó có thể giúp tôi trong việc thực hiện thực tế, nhưng một lần nữa tôi cảm thấy như nó có thể làm tôi chậm lại.

Nó làm bạn chậm lại bây giờ. Nhưng khi bạn phải gỡ lỗi hàng giờ thay vì ngày, bạn sẽ thay đổi suy nghĩ của mình.

mọi lời khuyên sẽ được đánh giá cao :)

Kiểm tra. Tin tôi đi Thật không may, nó cũng phải là một chính sách quản lý, nhưng đó là thứ giúp tiết kiệm thời gian. Các xét nghiệm ở lại, chúng ở đó, bây giờ và trong tương lai. Khi bạn thay đổi nền tảng và chạy thử nghiệm, và chúng vẫn hoạt động, bạn biết rằng công cụ của bạn hoạt động như mong đợi.

Chỉnh sửa: Tất nhiên tôi đã tham gia TDD pro / con dogpile và bỏ qua câu hỏi số 1:

1 - Thực hiện kiểm tra đơn vị trong các biểu mẫu web của ASP.net:

Trước hết, nếu bạn nghĩ rằng bạn có thể khiến họ đi với MVC, hãy chiến đấu vì nó như một con chó săn hung dữ. Là một nhà phát triển giao diện người dùng / giao diện người dùng, .net MVC là thứ giúp tôi ngừng ghét .net để tôi có thể tập trung tốt hơn vào việc ghét mọi giải pháp web Java mà tôi từng gặp phải. Các bài kiểm tra đơn vị có vấn đề vì các biểu mẫu web thực sự làm mờ các đường giữa máy chủ và phía máy khách. Trong bất kỳ nỗ lực nào để thực hiện kiểm tra đơn vị, tôi sẽ tập trung vào thao tác dữ liệu và (hy vọng) giả định các biểu mẫu web xử lý việc chuẩn hóa đầu vào của người dùng cho bạn dưới mui xe.

2 - Về việc kiểm tra đơn vị có đáng giá ở vị trí đầu tiên hay không:

Được rồi, tiết lộ đầy đủ:

• Tôi chủ yếu là tự học. Khóa đào tạo chính thức của tôi tập trung vào việc thích một JavaScript, PHP và lớp C # và nghiên cứu cá nhân của riêng tôi về các nguyên tắc OOP và đọc từ những thứ như Mẫu thiết kế.

Tuy nhiên,

• Tôi chủ yếu viết cho web phía máy khách và phần lập trình thực tế là một trong những ngôn ngữ nhanh và lỏng nhất hiện có liên quan đến gõ động, các hàm hạng nhất và khả năng biến đổi đối tượng.

Điều đó có nghĩa là, tôi không viết cho cùng một trình biên dịch hoặc máy ảo. Tôi viết cho 4-20 cách hiểu khác nhau về ba ngôn ngữ (vâng, hai trong số chúng chỉ đơn thuần là khai báo nhưng cũng xác định không gian vật lý cơ bản của UI mà tôi đang làm việc theo những cách khác nhau đôi khi) và đã làm như vậy vì các diễn giải là đa dạng hơn nhiều so với ngày nay. Và không, tôi không chỉ là một đứa trẻ cắm các công cụ JQuery cho các ứng dụng dùng một lần. Tôi giúp xây dựng và duy trì các công cụ khá phức tạp với nhiều độ phức tạp của yếu tố UI.

Vì vậy, có, có rất nhiều cơ hội cho một vài điều chỉnh ở đây và ở đó để tạo ra một loạt các thất bại lớn nếu kỹ năng thiết kế của bạn hoàn toàn tào lao hoặc bạn đang ném các nhà phát triển tầm thường với số lượng lớn 1-2 vấn đề về chất lượng.

Sự hiểu biết của tôi về những gì TDD cần phải làm cho bạn là các bài kiểm tra thực sự nhiều hơn về việc buộc bạn phải xem xét thiết kế cẩn thận hơn và giữ cho bạn tập trung vào các yêu cầu. Đủ công bằng, nhưng vấn đề ở đây là nó thay đổi những gì bạn nên làm, đang thiết kế thành một giao diện, thành một thứ gì đó tinh tế nhưng khác biệt cơ bản, đó là thiết kế để kiểm tra giao diện. Sự khác biệt với tôi là giữa việc vẽ một bức tranh rõ ràng mà mẹ sẽ không phải đoán ý nghĩa và lấp đầy toàn bộ trang bằng màu xanh lá cây thật nhanh để bạn có thể là đứa trẻ đầu tiên đập bút màu lên bàn và hét lên "xong! " Bằng cách thay đổi mức độ ưu tiên cho kết quả theo quy trình và thiết kế, về cơ bản, bạn đang khuyến khích tiếp tục triển khai mã rác, thường là nguyên nhân của vấn đề của bạn ở nơi đầu tiên.

Và dĩ nhiên, có "lợi ích không thực tế" nhưng thường được ca ngợi về lợi ích của các bài kiểm tra đơn vị giúp bạn phát hiện các lỗi hồi quy. Những người ủng hộ TDD có xu hướng hơi mơ hồ về việc liệu đây thực sự là mục tiêu hay chỉ là một tác dụng phụ tiện lợi, IMO, bởi vì họ biết rất rõ hoặc nghi ngờ rằng ít nhất điều này không đủ để thiết lập sự vắng mặt của lỗi trong bạn mã, đặc biệt là trong một ngôn ngữ năng động hơn như JavaScript, trong đó giả sử bạn thậm chí có thể dự đoán mọi tình huống có thể xảy ra trong một chuỗi dài các phụ thuộc là rất khó hiểu.

Có một nơi để kiểm tra tự động trong JS, nhưng việc sử dụng thời gian của bạn tốt hơn nhiều so với việc gắn một bài kiểm tra đơn vị vào mỗi 'đơn vị' mã của bạn tiếp xúc với người khác để đảm bảo bạn không có một bó các đối tượng rác trùng lặp công việc hoặc có mục đích sử dụng là mơ hồ về mặt ngữ nghĩa ở đó ngay từ đầu. Bạn làm theo nguyên tắc DRY. Bạn trừu tượng hóa mọi thứ để sử dụng lại / tính di động khi giá trị của việc đó trở nên rõ ràng (và không phải là một phút trước đó). Bạn thiết lập các quy trình và cách thức nhất quán để thực hiện nhiều thứ theo củ cà rốt hơn là nguyên tắc dính (nghĩa là quá dễ dàng để sử dụng công cụ của bạn đúng cách để bận tâm muốn làm sai cách). Và đối với tình yêu của tất cả mọi thứ foo và bar, bạn không bao giờ thưởng thức các mô hình kế thừa tầng lớn chống các mô hình như một phương tiện tái sử dụng mã.

Tất cả những điều trên đã giúp tôi giảm các lỗi khó chẩn đoán trong mã của mình một cách nghiêm túc và bạn có thể tin rằng đó là ưu tiên lớn đối với ai đó đã trở thành nhà phát triển với trình duyệt không có gì tốt hơn để nói với bạn hơn " uh đã xảy ra sự cố với một đối tượng thuộc loại 'Đối tượng' ở số dòng tưởng tượng này trong một tệp không xác định. " (gee, cảm ơn IE6) TDD, trong công việc của tôi, sẽ không khuyến khích những điều này. Nó sẽ chuyển trọng tâm sang kết quả 100% trong quá trình trong đó những gì giữa điểm A và B không thực sự quan trọng miễn là nó hoạt động. Thật lãng phí thời gian sẽ được áp dụng tốt hơn để đảm bảo công cụ của bạn dễ đọc, dễ mang theo và dễ dàng sửa đổi mà không có nhiều sự phá vỡ khó hiểu ngay từ đầu.

Hoặc có thể tôi chỉ đang nói quá nhiều về mô hình mà tôi bắt nguồn từ đó, nhưng theo tôi, làm việc đó ngay từ đầu là cách sử dụng thời gian hiệu quả hơn nhiều so với việc che mông của bạn khi bạn hoặc mọi người khác ở bên bạn Đội nào làm sai. Và không có gì nên buộc bạn phải xem xét thiết kế hơn là chỉ thực hiện mọi thứ. Thiết kế nên là bàn thờ kỳ dị của mọi lập trình viên. Và bất cứ điều gì "buộc bạn" phải làm điều đúng đắn hoặc bảo vệ bạn khỏi chính bạn nên được xem với cùng sự nghi ngờ dành riêng cho chai dầu rắn, IMO. Dầu rắn trong CNTT hiện đại và phát triển chung, nếu bạn chưa biết, được bán bởi tấn chất lỏng.

Theo kinh nghiệm của tôi, các bài kiểm tra đơn vị thực sự rất hữu ích, khi bạn bắt đầu với chúng và ở lại với chúng tức là Phát triển dựa trên thử nghiệm. Đây là lý do tại sao:

• Các bài kiểm tra đơn vị buộc bạn phải suy nghĩ về những gì bạn muốn và làm thế nào để xác minh rằng bạn đã nhận được nó, trước khi bạn viết mã thực hiện nó . Trong kịch bản TDD, bạn viết bài kiểm tra trước. Do đó, bạn phải biết mã mà bạn sắp viết cần phải làm gì và làm thế nào bạn có thể xác minh rằng nó đã thực hiện thành công, để viết một bài kiểm tra "đỏ" mà sau đó bạn thực hiện "xanh" bằng cách viết mã vào vượt qua nó Trong nhiều trường hợp, điều này buộc bạn phải suy nghĩ thêm một chút về thuật toán bạn sắp viết để vượt qua bài kiểm tra này, đây luôn là một điều tốt vì nó làm giảm các lỗi logic và "các trường hợp góc". Trong khi bạn đang viết bài kiểm tra, bạn đang nghĩ "làm thế nào điều này có thể thất bại" và "những gì tôi không kiểm tra ở đây", dẫn đến một thuật toán mạnh mẽ hơn.

• Các bài kiểm tra đơn vị buộc bạn phải suy nghĩ về cách mã bạn sắp viết sẽ được sử dụng . Trước khi tôi học TDD, đã có NHIỀU lần tôi viết mã mong đợi một người phụ thuộc làm việc theo một cách, và sau đó được trao cho một người phụ thuộc được viết bởi một đồng nghiệp làm việc theo cách hoàn toàn khác. Mặc dù điều này vẫn có thể với TDD, bài kiểm tra đơn vị bạn đang viết buộc bạn phải suy nghĩ về cách bạn muốn sử dụng đối tượng bạn đang viết, bởi vì đây là cách sử dụng ví dụ về đối tượng đã nói. Sau đó, bạn hy vọng sẽ viết đối tượng theo cách dễ tiêu thụ và do đó để thích ứng nếu cần thiết (mặc dù lập trình cho các giao diện được xác định trước là giải pháp tổng thể tốt hơn cho vấn đề này không cần TDD).

• Kiểm tra đơn vị cho phép bạn "mã bằng cách kiểm tra" . Một công cụ tái cấu trúc như ReSharper có thể là người bạn tốt nhất của bạn nếu bạn cho phép nó. Bạn có thể sử dụng nó để xác định bộ xương của chức năng mới vì bạn đang xác định việc sử dụng trong một thử nghiệm.

  Chẳng hạn, giả sử bạn cần tạo một đối tượng mới MyClass. Bạn bắt đầu bằng cách tạo một thể hiện của MyClass. "Nhưng MyClass không tồn tại!", ReSharper phàn nàn. "Sau đó tạo nó" bạn nói, với một lần nhấn Alt + Enter. Và uy tín bạn có định nghĩa lớp học của bạn. Trong dòng mã thử nghiệm tiếp theo, bạn gọi một phương thức MyMethod. "Nhưng điều đó không tồn tại!", ReSharper nói. "Sau đó tạo nó", bạn lặp lại, với Alt + Enter khác. Bạn có, với một vài lần nhấn phím, đã xác định "bộ xương" của mã mới. Khi bạn tiếp tục sử dụng, IDE sẽ cho bạn biết khi nào đó không phù hợp và thông thường giải pháp đủ đơn giản để IDE hoặc công cụ cắm vào nó biết cách khắc phục.

  Các ví dụ cực đoan hơn phù hợp với mô hình "Triple-A"; "Sắp xếp, hành động, khẳng định". Thiết lập mọi thứ, thực hiện logic thực tế mà bạn đang kiểm tra, sau đó khẳng định rằng logic là chính xác. Mã hóa theo cách này, rất tự nhiên để mã hóa giải pháp vào thử nghiệm; sau đó, với một vài lần nhấn phím, bạn có thể trích xuất logic đó và đặt nó ở đâu đó có thể sử dụng nó trong mã sản xuất, sau đó thực hiện các thay đổi nhỏ để kiểm tra chỉ ra vị trí mới của logic. Làm theo cách này buộc bạn phải kiến ​​trúc mã theo cách mô đun, dễ sử dụng lại vì các đơn vị bạn đang kiểm tra vẫn phải truy cập được.

• Các bài kiểm tra đơn vị chạy nhiều đơn đặt hàng có cường độ nhanh hơn bất kỳ bài kiểm tra thủ công nào bạn có thể nghĩ đến. Có một điểm, rất nhanh được đáp ứng trong trường hợp các dự án lớn hơn, trong đó chi phí thử nghiệm đơn vị bắt đầu tự trả bằng cách giảm thời gian thử nghiệm thủ công. Bạn phải LUÔN chạy mã bạn vừa viết. Theo truyền thống, bạn đã làm như vậy một cách thủ công, bằng cách khởi động một chương trình lớn, điều hướng qua UI để thiết lập tình huống bạn đã thay đổi hành vi và sau đó xác minh lại kết quả thông qua UI hoặc dưới dạng dữ liệu được tạo. Nếu mã là TDDed, bạn chỉ cần chạy thử nghiệm đơn vị. Tôi đảm bảo với bạn nếu bạn đang viết bài kiểm tra đơn vị tốt, tùy chọn sau sẽ nhanh hơn nhiều lần so với trước đây.

• Kiểm tra đơn vị bắt hồi quy . Một lần nữa, đã nhiều lần tôi học TDD nơi tôi đến, thực hiện điều tôi nghĩ là thay đổi phẫu thuật thành một đoạn mã, xác minh rằng sự thay đổi đã khắc phục một hành vi sai lầm (hoặc tạo ra một hành vi mong muốn mới) trong tình huống được báo cáo và kiểm tra nó để phát hành, chỉ để thấy rằng sự thay đổi đã phá vỡ một số trường hợp góc khác trong một mô-đun hoàn toàn khác xảy ra để sử dụng lại cùng một khối mã. Trong một dự án TDDed, tôi có thể viết một bài kiểm tra xác minh một thay đổi mà tôi sắp thực hiện, thực hiện thay đổi, sau đó chạy bộ đầy đủ và nếu tất cả các cách sử dụng mã khác là TDDed và thay đổi của tôi đã phá vỡ điều gì đó, các thử nghiệm cho những thay đổi đó những thứ khác sẽ thất bại, và tôi có thể điều tra.

  Nếu các nhà phát triển phải tự tìm và kiểm tra tất cả các dòng mã có thể bị ảnh hưởng bởi một thay đổi tiềm năng, thì sẽ không có gì được thực hiện vì chi phí xác định tác động của thay đổi sẽ khiến cho thay đổi không thể thực hiện được. Ít nhất, không có gì có thể RẮN và do đó dễ dàng duy trì, bởi vì bạn sẽ không bao giờ dám chạm vào thứ gì đó có thể được sử dụng ở nhiều nơi; thay vào đó, bạn sẽ cuộn giải pháp thay đổi rất giống nhau nhưng rất hợp nhất của mình cho trường hợp này, vi phạm SRP và có thể là OCP, và từ từ biến codebase của bạn thành một tấm chăn chắp vá.

• Đơn vị kiểm tra hình dạng kiến ​​trúc theo cách thường có lợi . Các bài kiểm tra đơn vị là các bài kiểm tra được thực hiện tách biệt với bất kỳ logic nào khác. Sau đó, để có thể kiểm tra mã của bạn, bạn phải viết mã theo cách mà bạn có thểcô lập nó Các quyết định thiết kế tốt như khớp nối lỏng lẻo và tiêm phụ thuộc do đó tự nhiên thoát khỏi quy trình TDD; phụ thuộc phải được tiêm để trong thử nghiệm, bạn có thể tiêm "giả" hoặc "sơ khai" tạo ra đầu vào hoặc xử lý đầu ra cho tình huống đang được thử mà không tạo ra "tác dụng phụ". Tâm lý "sử dụng đầu tiên" của TDD thường dẫn đến "mã hóa giao diện", bản chất của khớp nối lỏng lẻo. Các nguyên tắc thiết kế tốt này sau đó cho phép bạn thực hiện các thay đổi trong sản xuất, chẳng hạn như thay thế toàn bộ một lớp, mà không yêu cầu khối lượng lớn của cơ sở mã phải được thay đổi để thích nghi.

• Các thử nghiệm đơn vị cho thấy mã hoạt động, thay vì chứng minh mã hoạt động . Thoạt nhìn bạn có thể nghĩ rằng đó là một bất lợi; chắc chắn bằng chứng là tốt hơn so với trình diễn? Lý thuyết tuyệt vời; lý thuyết tính toán và thuật toán là nền tảng của công việc của chúng tôi. Nhưng, một bằng chứng toán học về tính đúng đắn của một thuật toán không phải là bằng chứng về tính đúng đắn của việc thực hiện . Một bằng chứng toán học chỉ cho thấy rằng mã tuân thủ thuật toán phải chính xác. Một thử nghiệm đơn vị cho thấy rằng mã thực sự được viết thực hiện những gì bạn nghĩ nó sẽ làm, và do đó là bằng chứng cho thấy nó là chính xác. Điều này thường có giá trị hơn nhiều so với một bằng chứng lý thuyết.

Bây giờ, tất cả những gì đã nói, có những bất lợi cho thử nghiệm đơn vị:

• Bạn không thể kiểm tra đơn vị mọi thứ. Bạn có thể kiến ​​trúc hệ thống của mình để giảm thiểu số lượng LỘC không được bao phủ bởi một bài kiểm tra đơn vị, nhưng khá đơn giản sẽ là một số khu vực nhất định của hệ thống không thể được kiểm tra đơn vị. Lớp truy cập dữ liệu của bạn có thể bị chế giễu khi được sử dụng bởi mã khác, nhưng bản thân lớp truy cập dữ liệu chứa rất nhiều tác dụng phụ và thường không khả thi để kiểm tra đơn vị (hầu hết?) Của Kho lưu trữ hoặc DAO. Tương tự, mã sử dụng các tệp, thiết lập kết nối mạng, v.v ... có sẵn các hiệu ứng phụ và bạn chỉ đơn giản là không thể kiểm tra đơn vị dòng mã thực hiện điều đó. Các yếu tố UI thường không thể được kiểm tra đơn vị; bạn có thể kiểm tra các phương thức mã hóa như trình xử lý sự kiện, bạn có thể đơn vị kiểm tra các hàm tạo và xác minh rằng các trình xử lý đã được cắm, nhưng đơn giản là không có thay thế trong mã cho người dùng nhấp chuột vào một yếu tố đồ họa cụ thể và xem trình xử lý được gọi. Đạt được các ranh giới giữa những gì có thể và không thể được kiểm tra đơn vị đầy đủ được gọi là "cạo cạnh của hộp cát"; ngoài thời điểm đó, bạn bị giới hạn trong việc sử dụng các thử nghiệm tích hợp, thử nghiệm chấp nhận tự động và thử nghiệm thủ công để xác minh hành vi.

• Nhiều lợi thế của kiểm tra đơn vị không áp dụng mà không có TDD. Hoàn toàn có thể viết mã, sau đó viết các bài kiểm tra thực thi mã. Chúng vẫn là "kiểm thử đơn vị", tuy nhiên bằng cách viết mã trước, bạn sẽ mất nhiều lợi thế vốn có trong phát triển "thử trước": mã không nhất thiết phải được kiến ​​trúc theo cách có thể dễ dàng kiểm tra hoặc thậm chí được sử dụng trong sản xuất ; bạn không có được quá trình suy nghĩ "kiểm tra hai lần" vốn có khi viết bài kiểm tra và suy nghĩ về những gì bạn đã nghĩ về; bạn không mã bằng cách kiểm tra; và nếu bạn viết mã, kiểm tra thủ công và xem nó hoạt động, sau đó mã kiểm tra đơn vị bị lỗi, đó là sai, mã hoặc kiểm tra? Ưu điểm chính của bạn là ngăn ngừa hồi quy (bạn sẽ được cảnh báo khi mã trước đó đã vượt qua các thử nghiệm của nó bây giờ không thành công) và xác minh tốc độ cao so với thử nghiệm thủ công. Mất TDD '

• Kiểm tra đơn vị giới thiệu một chi phí . Rất đơn giản, bạn đang viết mã để kiểm tra mã bạn đang viết. Điều này nhất thiết sẽ tăng tổng LỘC của một dự án phát triển và vâng, LỘC cho các thử nghiệm có thể vượt quá LỘC cho dự án thực tế. Các nhà phát triển và người không phát triển ngây thơ sẽ xem xét tình trạng này và nói rằng các thử nghiệm là một sự lãng phí thời gian.

• Kiểm tra đơn vị yêu cầu kỷ luật. Bạn phải viết các bài kiểm tra sẽ thực hiện đầy đủ codebase (độ bao phủ mã tốt), bạn phải chạy chúng thường xuyên (như bất cứ khi nào bạn thực hiện thay đổi, bộ đầy đủ sẽ được chạy) và bạn phải giữ mọi thứ "xanh" ( tất cả các bài kiểm tra qua). Khi mọi thứ bị hỏng, bạn phải sửa chúng bằng cách sửa mã không đáp ứng mong đợi hoặc bằng cách cập nhật các kỳ vọng của các thử nghiệm. Nếu bạn thay đổi các bài kiểm tra, bạn nên hỏi "tại sao" và theo dõi sát sao bản thân; thật vô cùng hấp dẫn khi chỉ cần thay đổi các xác nhận thất bại để phù hợp với hành vi hiện tại hoặc đơn giản là loại bỏ các thử nghiệm thất bại; nhưng, những bài kiểm tra đó phải dựa trên yêu cầu và khi hai bài kiểm tra không khớp với nhau thì bạn có vấn đề. Nếu những điều này không được thực hiện,

• Kiểm tra đơn vị yêu cầu nhiều thiết bị hơn. Giải pháp thông thường cho nhu cầu kỷ luật nói trên và xu hướng tự nhiên của con người là lười biếng và đồng hành, là "bot xây dựng" chạy gói phần mềm "Tích hợp liên tục" như TeamCity, CruiseControl, v.v., thực hiện các bài kiểm tra đơn vị, tính toán số liệu bảo hiểm mã và có các điều khiển khác, chẳng hạn như "triple-C" (tuân thủ quy ước mã hóa, la FxCop). Phần cứng cho bot xây dựng phải có hiệu suất hợp lý (nếu không nó sẽ không theo kịp tốc độ kiểm tra mã mà nhóm trung bình sẽ thực hiện) và các quy trình đăng ký trên bot phải được cập nhật (nếu một thư viện mới của các bài kiểm tra đơn vị được tạo ra, xây dựng các tập lệnh chạy các bài kiểm tra đơn vị phải được thay đổi để tìm trong thư viện đó). Đây là công việc ít hơn nó có vẻ, nhưng thường đòi hỏi một số chuyên môn kỹ thuật về phía ít nhất một vài người trong nhóm, những người biết cách thức hoạt động của các quy trình xây dựng khác nhau (và do đó có thể tự động hóa chúng trong các tập lệnh và duy trì các tập lệnh đã nói). Nó cũng vẫn đòi hỏi kỷ luật dưới hình thức chú ý khi bản dựng "phá vỡ" và sửa bất cứ điều gì khiến bản dựng bị hỏng (chính xác) trước khi kiểm tra bất cứ điều gì mới.

• Kiểm thử đơn vị có thể buộc mã được kiến ​​trúc theo cách không lý tưởng . Mặc dù TDD thường tốt cho tính mô đun và khả năng sử dụng lại mã, nhưng nó có thể gây bất lợi cho khả năng tiếp cận mã phù hợp. Các đối tượng và thành viên, được đặt trong các thư viện sản xuất, không thể là riêng tư hoặc nội bộ nếu chúng được sử dụng trực tiếp bởi các thử nghiệm đơn vị. Điều này có thể gây ra vấn đề khi các lập trình viên khác, hiện đang nhìn thấy một đối tượng, cố gắng sử dụng nó khi họ nên sử dụng một cái gì đó có trong thư viện. Đánh giá mã có thể giúp với điều này, nhưng nó có thể là một mối quan tâm.

• Kiểm thử đơn vị thường cấm các kiểu mã hóa "phát triển ứng dụng nhanh". Nếu bạn đang viết bài kiểm tra đơn vị, bạn không mã hóa "nhanh và lỏng". Đó thường là một điều tốt, nhưng khi bạn ở dưới thời hạn áp đặt ngoài tầm kiểm soát của bạn, hoặc bạn đang thực hiện một thay đổi trong phạm vi rất nhỏ và các bên liên quan (hoặc sếp của bạn) đang tự hỏi tại sao tất cả các hành trình này phải xảy ra chỉ để thay đổi một dòng mã, đơn giản là không thể viết và duy trì bộ kiểm thử đơn vị thích hợp. Các quy trình nhanh nhẹn thường giúp với điều này bằng cách cho phép các nhà phát triển lên tiếng trong các yêu cầu về thời gian; hãy nhớ rằng, tất cả những người bán hàng phải làm là nói "vâng, chúng tôi có thể" và họ được kiểm tra hoa hồng, trừ khi quy trình liên quan đến những người phải thực sự làm công việc nói "không chúng tôi không thể" và được chú ý. Nhưng, không phải Agile của mọi người và Agile đều có những hạn chế riêng.

Các bài kiểm tra đơn vị rất hữu ích khi được sử dụng đúng cách; có nhiều vấn đề với logic của bạn.

"Khi tôi đang phát triển, tôi đã trải qua rất nhiều thử thách và lỗi" Kevin nói.

Nhìn vào lập trình bởi sự trùng hợp. Tốt hơn là nên hiểu những gì một mã nên làm và sau đó chứng minh rằng nó thực hiện nó thông qua một bài kiểm tra đơn vị. Đừng cho rằng mã hoạt động đơn giản vì UI không bị hỏng khi bạn chạy chương trình!

s writing unit tests for ASP.NET web forms something that is done often

Tôi không có kiến ​​thức về dữ liệu thống kê để nói tần suất mọi người kiểm tra các biểu mẫu web. Không quan trọng. Giao diện người dùng khó kiểm tra và Kiểm tra đơn vị cũng không nên được kết hợp với giao diện người dùng. Phân tách logic của bạn thành các lớp, thư viện lớp có thể được kiểm tra. Kiểm tra UI riêng biệt với logic back-end.

So, question number 2: Would you guys advise me to start writing unit tests?

Đúng. Khi bạn đã quen với chúng, chúng sẽ tăng tốc cho bạn. Bảo trì tốn nhiều thời gian và chi phí hơn nhiều so với giai đoạn phát triển ban đầu. Bảo trì được hỗ trợ rất nhiều với các bài kiểm tra đơn vị, ngay cả với kiểm tra ban đầu và sửa lỗi.

Ở mức độ thực tế Các bài kiểm tra đơn vị có thể cực kỳ hữu ích vì một lý do rất quan trọng: Bạn có thể kiểm tra một bit mã tại một thời điểm.

Khi bạn đang viết một chuỗi các bước phức tạp và gỡ lỗi chúng ở cuối, bạn có xu hướng tìm thấy nhiều lỗi và quá trình này thường khó hơn vì bạn sẽ tiếp tục trong quá trình này. Trong Visual Studio, bạn có thể tạo một thử nghiệm nhanh, thay đổi một chút và chạy CHỈ thử nghiệm đó .. Sau đó, bạn biết rằng ví dụ một phương thức gọi phương thức đó có thể dựa vào nó. Vì vậy, nó làm tăng sự tự tin.

Bài kiểm tra đơn vị không chứng minh rằng chương trình của bạn là chính xác! : Kiểm tra đơn vị kiểm tra hồi quy trong mã nhạy cảm và cho phép bạn kiểm tra các phương thức mới mà bạn viết.

Kiểm thử đơn vị không nhằm kiểm tra các giao diện người dùng : Hãy nghĩ về kiểm thử đơn vị vì dự án nhỏ mà bạn tạo để kiểm tra một phương thức mới mà bạn đang viết hoặc một cái gì đó, không phải là một điều kiện mà mã của bạn cần đáp ứng.

Kiểm thử đơn vị hoạt động rất tốt cho môi trường hợp tác : Nếu tôi phải cung cấp phương pháp cho một đồng nghiệp đang sử dụng công nghệ hoàn toàn khác để khai thác, ví dụ như anh ta đang gọi nó từ iOS, thì tôi có thể nhanh chóng viết thử nghiệm đơn vị để xem phương pháp anh ta muốn a) Truy xuất lại dữ liệu chính xác b) Thực hiện theo thông số kỹ thuật của anh ta c) Không có bất kỳ tắc nghẽn khó chịu nào.

Một điều dường như không được chạm vào là sự phức tạp của việc thử nghiệm các loại mã khác nhau.

Khi bạn đang xử lý các công cụ với đầu vào và đầu ra đơn giản, việc kiểm tra đơn vị nói chung rất dễ dàng và nếu các thử nghiệm được chọn với các trường hợp cạnh của mã được kiểm tra, chúng sẽ giúp bạn tự tin rằng chúng đúng. Không viết bài kiểm tra cho mã như vậy sẽ là điên rồ. (Lưu ý rằng hầu hết các mã đi vào thư viện đều đáp ứng tiêu chí này.)

Tuy nhiên, trong các trường hợp khác, cuối cùng bạn phải xây dựng các giả lớn để kiểm tra vì mã đang phát với dữ liệu cơ bản phức tạp (thường là cơ sở dữ liệu nhưng không phải như vậy) hoặc tạo ra dữ liệu đầu ra rất phức tạp (nghĩ về một thói quen biến một giá trị hạt giống vào cấp độ trò chơi cho một ví dụ khá khắc nghiệt) và thử nghiệm đơn vị gần như không hữu ích. Bao gồm tất cả mọi thứ trong các trường hợp thử nghiệm của bạn thường là một giấc mơ xa vời và khi bạn tìm thấy một lỗi thì hầu như luôn luôn là một trường hợp mà bạn không bao giờ nghĩ tới và do đó không thể xây dựng một thử nghiệm nào.

Không có viên đạn bạc, bất cứ thứ gì được miêu tả là viên đạn bạc gần như không tốt như những người đề xướng tuyên bố nhưng điều đó không có nghĩa là nó vô dụng.

Viết các bài kiểm tra đơn vị cho ứng dụng biểu mẫu ASP.NET Web KHÔNG phổ biến và rất khó thực hiện. Tuy nhiên, điều đó không có nghĩa là dự án nên bỏ qua nó.

Các bài kiểm tra đơn vị là corner stonescác ứng dụng quan trọng và chúng cung cấp độ tin cậy và sự an tâm rằng chức năng cốt lõi thực hiện như mong đợi.

Trên thực tế, bạn có thể giới thiệu thử nghiệm đơn vị dễ dàng hơn nhiều với mẫu ASP.NET MVP có thể được sử dụng trong phát triển biểu mẫu web của bạn. Nó sẽ giới thiệu sự tách biệt của mối quan tâm và ability to write essential unit tests.

Một số tài liệu tham khảo có thể hữu ích để xem là:

• Bắt đầu với việc thử nghiệm Ứng dụng ASP.NET Webforms (Mẫu MVP)
• Thực hiện và kiểm tra chuyển hướng với ASP.NET Web Forms MVP
• Trình chiếu Model View với ASP.NET - CodeProject

Mục đích của kiểm tra đơn vị là cho phép bạn thay đổi mã của mình một cách an toàn (tái cấu trúc, cải thiện, v.v.) mà không sợ bạn có thể phá vỡ thứ gì đó bên trong hệ thống. Điều này chứng tỏ rất hữu ích cho các ứng dụng lớn, khi bạn không thực sự biết tất cả các tác động của việc thay đổi mã của mình (mặc dù khớp nối lỏng lẻo).

Đó là kinh nghiệm của tôi rằng có , bài kiểm tra đơn vị là hữu ích.

Kiểm thử đơn vị là về cách ly các phần của mã bạn viết và đảm bảo rằng chúng hoạt động độc lập. Sự cô lập này thực sự có thể liên quan đến việc tạo các đối tượng giả hoặc giả để nói chuyện với đối tượng bạn đang thử nghiệm, hoặc có thể không. Nó phụ thuộc rất nhiều vào kiến ​​trúc của đối tượng của bạn.

Thử nghiệm đơn vị cấp các lợi ích khác nhau:

Chủ yếu, điều này đảm bảo rằng các đơn vị bạn kiểm tra hoạt động theo cách bạn, nhà phát triển, nghĩ rằng họ nên làm việc. Trong khi điều này ít hơn âm thanh: không nhất thiết phải nói rằng đối tượng đang hoạt động chính xác; chỉ có điều nó hoạt động theo cách bạn nghĩ nó nên hoạt động, đó là một tuyên bố mạnh mẽ hơn nhiều so với phương pháp thử và sai cần thiết mà không cần kiểm thử đơn vị.

Ngoài ra, nó đảm bảo rằng các đơn vị tiếp tục hoạt động theo cách bạn, nhà phát triển, nghĩ rằng họ nên làm việc. Phần mềm thay đổi, và điều này có thể tác động đến các đơn vị theo những cách không mong muốn.

Một tác dụng phụ là nó có nghĩa là các đơn vị bạn kiểm tra làm việc trong sự cô lập. Điều này thường có nghĩa là bạn bắt đầu lập trình cho các giao diện thay vì các lớp cụ thể, giảm khớp nối và tăng sự gắn kết: tất cả các đặc điểm chung của thiết kế tốt. Có: chỉ đơn thuần cho phép các đơn vị mã của bạn có các bài kiểm tra đơn vị sẽ tự nhiên cải thiện thiết kế mã của bạn.

Tuy nhiên...

Kiểm thử đơn vị không phải là kết thúc kiểm tra. Các loại thử nghiệm khác vẫn được yêu cầu. Ví dụ: ngay cả khi bạn đã chỉ ra rằng các đơn vị hoạt động theo cách bạn mong đợi chúng hoạt động, bạn vẫn cần chỉ ra rằng mỗi đơn vị hoạt động theo cách các đơn vị nói chuyện với đơn vị đó sẽ hoạt động. Đó là, các thành phần của bạn tích hợp với nhau một cách chính xác?

Đối với các ứng dụng đơn giản có số lượng lớp nhỏ để kiểm tra (Cửa sổ chính -> menu phụ), có lẽ biên dịch để chạy để kiểm tra các thay đổi là ok.

Đối với các ứng dụng lớn hơn, phải mất 30 giây điều hướng để có được trang bạn đang kiểm tra, điều này cuối cùng rất tốn kém ..

Tôi muốn thêm một mặt mới (thực ra là một mặt khá cũ) vào đây: các thử nghiệm đơn vị không hữu ích nếu mã của bạn được thiết kế tốt .

Tôi biết hầu hết các lập trình viên không làm thiết kế chương trình nữa, tôi vẫn làm và tôi thấy các bài kiểm tra đơn vị là một việc khá tốn thời gian để phù hợp với văn hóa TDD, nhưng cho đến nay, tôi mới chỉ gặp 1-2 lỗi trên hàng ngàn dòng kiểm tra mã của tôi - không chỉ những gì tôi đã viết, mà cả những người kiểm tra chính thức cũng đã viết.

Tôi đoán bạn sẽ không làm thiết kế chương trình nữa - những người hiện tại sẽ ép bạn vào một khuôn mẫu không làm điều đó - nhưng có lẽ nên nhớ rằng thử nghiệm đơn vị là một phương pháp hiệu quả rất thấp so với thiết kế.

Đây là một đối số dijsktraian: kiểm tra đơn vị chỉ có thể được thực hiện đối với một chương trình đủ chi tiết để chạy.

Nếu bạn vẽ sơ đồ / sơ đồ trạng thái / hành động, sơ đồ trình tự, hàng tồn kho đối tượng (và cuối cùng là sơ đồ lớp) cho mã của bạn trước khi thực sự viết nó, bạn sẽ có thể tiêu diệt hầu hết các lỗi có khả năng đe dọa chỉ bằng cách truy tìm xung quanh dòng của bạn và kiểm tra tên của bạn.

Ngày nay các sơ đồ lớp được tạo từ mã, chứa hàng trăm, đôi khi hàng ngàn lớp và hoàn toàn không sử dụng được - mọi thứ chứa hơn 15 phần tử đều nằm ngoài sự công nhận của con người.

Bạn phải biết 10 + -5 lớp nào quan trọng hoặc bạn làm gì ngay bây giờ và có thể kiểm tra mã của bạn từ nhiều quan điểm, mỗi sơ đồ thể hiện CHÍNH XÁC các quan điểm bạn đang xem và bạn sẽ tiêu diệt hàng ngàn lỗi trên giấy.

• Kiểm tra mã động nếu các loại được đáp ứng (chỉ đơn giản là hiển thị các loại đầu vào / đầu ra trên sơ đồ và kết nối chúng bằng bút chì hoặc màu khác),
• kiểm tra nếu tất cả các trạng thái được xử lý (bằng cách kiểm tra tính đầy đủ của các điều kiện của bạn),
• truy tìm các dòng để đảm bảo mọi thứ kết thúc (mỗi sơ đồ phải là một máy tự động trạng thái hữu hạn xác định được xác định đầy đủ, dành cho người có đầu óc toán học
• đảm bảo rằng các thành phần nhất định không liên quan gì đến nhau (bằng cách trích xuất tất cả các phụ thuộc của chúng) (tốt cho bảo mật)
• đơn giản hóa mã bằng cách chuyển đổi các phụ thuộc thành các hiệp hội (các phụ thuộc đến từ các lớp mà các phương thức thành viên sử dụng)
• kiểm tra tên, tìm kiếm các tiền tố phổ biến, xóa các từ đồng nghĩa, v.v ...

dễ dàng hơn nhiều ...

Ngoài ra, tôi phát hiện ra rằng các ứng dụng của mình có thể sử dụng được nhiều hơn, nếu chúng đến trực tiếp từ các trường hợp sử dụng ... nếu các trường hợp sử dụng được viết tốt (chủ đề động từ của người dùng, yêu cầu bảo trì để mở máy rút tiền) ...

Tôi đã làm mã với 95 +% số lần che mã. Tất nhiên, đôi khi tôi làm bài kiểm tra đơn vị, đặc biệt. để kiểm tra ranh giới trong các tính toán, nhưng tôi vẫn chưa đạt được hồi quy nghiêm trọng (nghiêm trọng: không bị xóa sổ trong 24 giờ) vì không sử dụng các bài kiểm tra đơn vị ngay cả đối với các phép tái cấu trúc.

Đôi khi tôi không làm một dòng mã nào trong 3-4 ngày liên tục, chỉ vẽ. Sau đó, trong một ngày, tôi gõ 1500-2000 dòng. Vào ngày hôm sau, họ chủ yếu sẵn sàng sản xuất. Đôi khi các bài kiểm tra đơn vị được viết (với 80% bảo hiểm), đôi khi (ngoài ra) những người kiểm tra được yêu cầu thử phá vỡ nó, mỗi lần, một số người được yêu cầu xem lại bằng cách xem nó.

Tôi chưa thấy các bài kiểm tra đơn vị tìm thấy bất cứ điều gì.

Tôi ước rằng tư duy thiết kế sẽ thay thế TDD ... nhưng TDD thì dễ dàng hơn nhiều, nó giống như đi với một chiếc búa tạ ... thiết kế cần suy nghĩ, và bạn thường xuyên rời khỏi bàn phím.