Có bất kỳ giá trị nào khi viết bài kiểm tra đơn vị cho mã đã hoạt động khi kế thừa ứng dụng không?

Rõ ràng một số ứng dụng cũ không thể hoặc cực kỳ khó kiểm tra đơn vị vì cách nó được viết ở vị trí đầu tiên.

Nhưng ở những nơi, giống như một số phương thức trợ giúp có thể được thử nghiệm đơn vị, tôi có nên bận tâm viết thử nghiệm đơn vị cho chúng không?

Ý tôi là, chúng có thể được viết như một con chó, nhưng logic rất phức tạp, bài kiểm tra thời gian đã chứng minh rằng nó hoạt động theo cách nó nên. Tôi chỉ nên bận tâm đến bài kiểm tra đơn vị nếu tôi nói đang kiểm tra lại nó hay tôi nên viết bài kiểm tra đơn vị cho họ bất cứ khi nào tôi có thời gian?

Có bất kỳ giá trị trong việc này?

Cũng tính đến việc định nghĩa phương pháp có thể mơ hồ và tôi có thể cần nghiên cứu một số phương pháp thực sự nên làm trong các điều kiện nhất định.

Tôi nghĩ bạn chắc chắn nên viết càng nhiều bài kiểm tra cho ứng dụng càng tốt. Họ sẽ giúp bạn tìm hiểu cơ sở mã và chuẩn bị cho bạn tái cấu trúc cuối cùng hoặc phát triển mới.

Có một vài loại bài kiểm tra bạn có thể viết trong kịch bản đó, mỗi bài kiểm tra đều có giá trị riêng. Viết các bài kiểm tra này sẽ dạy cho bạn rất nhiều về ứng dụng bạn đang xử lý.

Trước hết, trước khi bạn đặt ra các bài kiểm tra viết cho chính xác, hãy viết các bài kiểm tra nắm bắt hành vi hiện tại , dù đúng hay sai. Đây là một đặt cược khá an toàn rằng bạn sẽ phát hiện ra các lỗi trong các trường hợp góc hoặc trong các phần của mã không được kiểm tra kỹ lưỡng bằng cách chạy chương trình. Đừng lo lắng về những gì mã nên làm, chỉ cần nắm bắt những gì nó làm. Khi bạn tiến hành, đừng lo lắng về việc đọc mã hoặc dành thời gian nghiêm túc để tìm ra đầu ra nên là gì. Chỉ cần chạy thử nghiệm của bạn và nắm bắt đầu ra đó một cách khẳng định.

Điều đó sẽ cung cấp cho bạn một cơ sở hiểu biết vững chắc về cách thức hoạt động của mã và nơi các điểm đau chính hoặc các khu vực yếu có thể. Nếu bạn phát hiện ra lỗi, bạn có thể tiếp cận những người có quyền quyết định xem họ có đáng sửa hay không và đưa ra những quyết định đó.

Tiếp theo, bạn có thể viết một vài thử nghiệm lớn hơn (trong phạm vi) bao gồm các phần của mã có thể không dễ kiểm tra đơn vị nhưng trong đó vẫn rất quan trọng để kiểm tra quy trình công việc càng nhiều càng tốt. Các kiểm tra quy trình công việc hoặc kiểm tra tích hợp này , tùy thuộc vào cách bạn muốn xem xét chúng, sẽ cung cấp cho bạn cơ sở tốt để tái cấu trúc các quy trình công việc đó để chúng dễ kiểm tra hơn và bảo vệ bạn khi cần thêm một tính năng mới có thể ảnh hưởng đến quy trình công việc hiện có.

Theo thời gian, bạn sẽ xây dựng một bộ các bài kiểm tra có sẵn để giúp bạn hoặc người tiếp theo kết thúc kế thừa ứng dụng.

Tôi thấy các bài kiểm tra đơn vị là thông số kỹ thuật, không chỉ kiểm tra. Trong trường hợp cụ thể bạn đã đề cập, giá trị thực sẽ đến khi bạn có một bài kiểm tra đơn vị trước khi thực hiện bất kỳ thay đổi nào để phù hợp với đặc điểm kỹ thuật mới. Nếu bạn định thay đổi mã được kế thừa thì cách tốt nhất tôi thấy là kiểm tra đơn vị cho chức năng, điều này không chỉ mang lại một mạng lưới an toàn mà còn giúp chúng tôi hiểu rõ hơn về những gì đơn vị cụ thể đó làm. Nó cũng có thể buộc bạn phải thực hiện một số nghiên cứu như được đề cập bởi bạn, điều này tốt cho sự hiểu biết. Vì vậy, việc của tôi là để có được bài kiểm tra đơn vị của một mô-đun trước khi nó sắp trải qua một sự thay đổi.

 > Is there any value in writing unit tests for code that 
 > already works when inheriting applications?

NO . Theo kinh nghiệm của tôi, có một mối quan hệ chi phí / lợi ích tồi tệ khi viết các bài kiểm tra đơn vị sau khi mã sản xuất được viết bởi vì rất khó / khó tìm cách kiểm tra mã một cách riêng lẻ mà không cần tái cấu trúc nặng. Một trong những lợi ích của phát triển theo hướng kiểm tra là bạn có được mã ghép lỏng lẻo. Nếu bạn viết các bài kiểm tra sau đó thì rất có thể mã được ghép chặt chẽ.

CÓ, bạn có thể viết các bài kiểm tra Tích hợp cho ứng dụng cho các chức năng mà bạn dự định thực hiện thay đổi. Bằng cách này, bạn có thể có kiểm tra hồi quy để xem các thay đổi của bạn có phá vỡ điều gì không.

CÓ từ quan điểm chất lượng và nhà phát triển, việc kiểm tra là rất có giá trị.

KHÔNG theo quan điểm kinh doanh vì rất khó bán cho khách hàng rằng bạn cần thời gian / tiền bạc để không nhận được giá trị kinh doanh thực sự nhưng lời hứa mơ hồ rằng những thay đổi trong kinh doanh sẽ không làm mọi thứ tồi tệ hơn.

Nếu có thể, thậm chí còn có nhiều lý do hơn để viết các bài kiểm tra cho mã hiện có "đã hoạt động". Nếu không có thử nghiệm thì rất có thể mã đã chín mùi và có thể sử dụng tái cấu trúc mở rộng để được cải thiện; bộ kiểm tra sẽ giúp bạn tái cấu trúc. Nó thậm chí có thể tiết lộ rằng mã gốc không hoạt động đúng; Tôi nhớ lại một lần tôi đã viết một bài kiểm tra cho một phương pháp tạo ra một báo cáo bán hàng và tôi thấy nó không tính toán được mọi thứ một cách hợp lý nên doanh số cao hơn vài nghìn đô la so với thực tế và không ai biết rằng trong năm năm đó, mã được sản xuất (may mắn thay, đó không phải là kết thúc tài chính thực tế, chỉ là ước tính báo cáo bán hàng).

Tất nhiên, lời khuyên này chỉ áp dụng nếu bạn thực sự có thể viết các bài kiểm tra. Theo kinh nghiệm của tôi, một cơ sở mã không có kiểm tra gần như không thể trang bị thêm các kiểm tra vì bạn sẽ phải viết lại một nửa các mô-đun mã để đủ trừu tượng để hỗ trợ kiểm tra trước và bạn sẽ không thể làm điều đó.

Hoàn toàn có , bởi vì các bài kiểm tra đơn vị không nên xác minh tính đúng đắn mà đặc trưng cho hành vi thực tế của hệ thống. Đặc biệt với một dự án cũ, nhiều yêu cầu được mã hóa ngầm trong hành vi thực tế.

Đặc tính này phục vụ như là một đường cơ sở của chức năng. Ngay cả khi hành vi không chính xác theo quan điểm kinh doanh, bạn sẽ ngăn chặn hành vi xuống cấp xa hơn. Đạt được lực kéo trong một dự án cũ có thể khó khăn, và điều này cung cấp cho bạn một đường cơ sở để bạn có thể tiến về phía trước mà không làm mọi thứ tồi tệ hơn.

Vì vậy, viết tất cả các bài kiểm tra đơn vị bạn có thể. Đối với mã không thể được kiểm tra, hãy cấu trúc lại mã của bạn để phân tách các phụ thuộc bằng cách đưa "đường nối" vào mã - các vị trí nơi bạn có thể tách mã bạn muốn kiểm tra khỏi mã mà bạn không muốn kiểm tra.

Ý tưởng của các bài kiểm tra đơn vị như các bài kiểm tra đặc tính và các đường nối là những điểm chính trong Làm việc hiệu quả với Bộ luật kế thừa của Michael Feathers, một cuốn sách mà tôi rất khuyến khích.

Bản thân tôi đã suy nghĩ về điều này vì có khá nhiều văn bản được viết không rõ ràng, nhưng làm việc mã trong hệ thống của chúng tôi.

Bạn đưa ra một quan điểm tốt:

Tôi chỉ nên bận tâm đến bài kiểm tra đơn vị nếu tôi nói đang kiểm tra lại nó hay tôi nên viết bài kiểm tra đơn vị cho họ bất cứ khi nào tôi có thời gian?

Nếu các yêu cầu thay đổi, tôi nghĩ sẽ rất có giá trị khi viết các bài kiểm tra đơn vị. Nếu không tôi sẽ không bận tâm đặc biệt vì bạn sẽ không thể viết bài kiểm tra thích hợp, bởi vì bạn không biết tất cả các điều kiện.

Bất cứ khi nào tôi có thời gian?

Bạn có thời gian khi nó được ưu tiên, phải không?, Vì vậy nó sẽ không bao giờ xảy ra. :)

Bạn đang cố gắng tận dụng các khía cạnh của cơ sở mã mà trước đây chưa được sử dụng trong một ứng dụng sản xuất? Viết bài kiểm tra đơn vị cho các kịch bản đầu tiên. Bạn cần có khả năng ưu tiên công việc của mình ở đây và tôi nghĩ rằng Nghệ thuật kiểm thử đơn vị có một số lời khuyên về vấn đề đó (đặc biệt là cách tiếp cận kiểm tra các cơ sở mã kế thừa).

Đừng cho rằng mọi thứ đều hoạt động chỉ vì ứng dụng đang hoạt động ... thông thường, "thử thách thời gian" chỉ cho thấy rằng a) bạn chưa tìm thấy phần còn lại của các khiếm khuyết hoặc b) những người đã tìm thấy họ đã không báo cáo họ. (Hoặc có lẽ cả hai.) Và ngay cả mã có lẽ đang hoạt động bây giờ có thể không hoạt động vào lần tiếp theo bạn phải thực hiện thay đổi.

Các bài kiểm tra đơn vị cung cấp cho bạn một thước đo về sự chắc chắn rằng chức năng nhất định vẫn còn nguyên vẹn, đồng thời cung cấp cho bạn một cách để chứng minh điều này cho một số lượng hợp lý các trường hợp. Điều đó có giá trị hơn đáng kể so với "chọc xung quanh và kiểm tra điều này", ngay cả đối với một sửa lỗi. (Poking xung quanh giống như kiểm tra tích hợp hoặc kiểm tra hệ thống, do đó, theo nghĩa đó, kiểm tra thủ công ứng dụng có thể bao gồm nhiều hơn các thử nghiệm đơn vị có thể, nhưng đó vẫn là thời gian không hiệu quả. Ngay cả một số phương pháp tự động hóa các thử nghiệm đó là tốt hơn là làm chúng bằng tay.)

Bạn chắc chắn nên viết các bài kiểm tra khi bạn thay đổi mã, cho dù đó là sửa lỗi hoặc tái cấu trúc. Bạn có thể làm tốt việc viết bài kiểm tra nếu có thể, nếu không vì lý do nào khác ngoài việc tiết kiệm thời gian vào lần tới khi bạn phải sửa lỗi (và sẽ có lần sau) ... mặc dù trong trường hợp này, bạn sẽ phải cân bằng thời gian đó với mong đợi của những người giả vờ rằng phần mềm luôn không có khiếm khuyết và do đó thời gian dành cho việc bảo trì trong tương lai là "lãng phí". (Tuy nhiên, điều đó không có nghĩa là bạn nên bỏ qua lịch trình hiện tại.) Tại một số điểm, nếu bạn làm điều này, bạn sẽ có đủ bảo hiểm để bạn có thể bắt đầu chứng minh giá trị của thử nghiệm trên các ứng dụng cũ và điều đó có thể giúp bạn chi tiêu thời gian đó cho các ứng dụng trong tương lai, cuối cùng sẽ giải phóng thời gian để phát triển năng suất.

Từ trái tim đất liền của tôi , tôi sẽ nói đồng ý và không chỉ vậy, nhưng hãy hack nó, tái cấu trúc nó và tiếp tục thử nghiệm, nhưng hãy chắc chắn rằng bạn không bị lạc hậu trong các dự án quan trọng khác. Là một lập trình viên làm việc, Nếu công việc của bạn gặp rủi ro hoặc nếu người quản lý bảo bạn nắm quyền sở hữu thì có. Nếu nhóm hoặc công ty có thể bị thiệt hại, hãy thương lượng với người quản lý của bạn để cho anh ta biết rằng cần phải làm thử nghiệm để giữ cho công ty khỏi thảm họa. Nếu anh ta nói đừng lo lắng, thì bạn sẽ thoát ra khỏi tầm ngắm (không nhất thiết, đổ lỗi cho phái đoàn là một kỹ năng quản lý, vì vậy hãy chắc chắn rằng bạn đã thoát khỏi tình trạng ... thực sự!)

Chúc may mắn!