Bắt đầu với TDD?

Question

Chúng tôi đang trong giai đoạn đầu của việc cố gắng thực hiện TDD. Tôi đã giới thiệu cho các công cụ TDD của Visual Studio Team System và nhóm nghiên cứu rất vui mừng về các khả năng. Hiện tại chúng tôi sử dụng Devpartner để bảo vệ mã, nhưng chúng tôi muốn loại bỏ nó bởi vì nó đắt tiền. Chúng tôi có kinh nghiệm rất hạn chế trong TDD và muốn đảm bảo rằng chúng tôi không đi sai hướng. Hiện tại chúng tôi đang sử dụng SourceSafe để kiểm soát nguồn nhưng sẽ di chuyển sang Hệ thống nhóm trong khoảng một năm.

Tôi có thể cho bạn biết các ứng dụng của chúng tôi rất tập trung vào dữ liệu. Chúng tôi có khoảng 900 bảng, 6000 thủ tục được lưu trữ và khoảng 45GB dữ liệu. Chúng tôi có rất nhiều tính toán dựa trên tỷ lệ người dùng và tỷ lệ khác nhau trong hệ thống. Ngoài ra rất nhiều mã của chúng tôi dựa trên thời gian (tính lãi cho ngày hiện tại). Một số tính toán này rất phức tạp và rất chuyên sâu (chỉ một số ít người biết chi tiết cho một số người trong số họ).

Chúng tôi muốn triển khai TDD để giải quyết các vấn đề về QA. Rất nhiều nhà phát triển buộc phải sửa lỗi trong các lĩnh vực mà họ không quen thuộc và cuối cùng phá vỡ một cái gì đó. Ngoài ra còn có các khu vực mà các nhà phát triển hầu như sợ liên lạc vì mã được sử dụng bởi tất cả mọi thứ trong hệ thống. Chúng tôi muốn giảm thiểu vấn đề này.

Tôi sợ vì mã của chúng tôi tập trung vào dữ liệu nên việc triển khai TDD có thể phức tạp hơn một chút so với hầu hết các hệ thống. Tôi đang cố gắng để tìm ra một gameplan mà tôi có thể trình bày để quản lý nhưng tôi muốn hy vọng không bị cuốn vào một số sai lầm mới bắt đầu TDD. Ngoài ra nếu các công cụ/cơ sở trong Team System làm cho TDD hoàn thiện hơn thì điều đó sẽ tốt đẹp nhưng chúng tôi không muốn đợi Team System bắt đầu.

Câu hỏi đầu tiên mà chúng tôi yêu cầu là chúng ta nên bắt đầu với các công cụ trong studio trực quan? Tôi đã đọc bài viết là mọi người phàn nàn về các công cụ nội tại trong studio trực quan (cần tạo một dự án riêng để tạo thử nghiệm) nhưng một điều về các công cụ trong studio trực quan là miễn phí và tích hợp tốt. Nếu chúng tôi quyết định sử dụng thứ gì đó như XUnit, MBUnit hoặc NUnit thì chúng tôi rất có thể sẽ có một số chi phí đáng kể:

1) Nếu chúng tôi muốn Tích hợp IDE (không đề cập đến hầu hết mã của chúng tôi) là VB.Net)
---TestDriven.Net hoặc Resharper hoặc ?????

2) Nếu chúng ta muốn bảo hiểm mã
--- NCover (Có vẻ khá đắt tiền cho các chức năng của nó)

Ngoài ra tôi đã nhìn thấy một số chức năng khá mát mẻ demoed trong visual studio 2010. Giống như khả năng để làm đầu vào kiểm tra (dữ liệu được nhập trên biểu mẫu) hoặc khả năng ghi lại những gì người dùng đã thực hiện và sau đó cấp dữ liệu đó vào thử nghiệm đơn vị của bạn để tạo lại sự cố.

Ngoài ra, mặc dù tôi không hoàn toàn nắm bắt được khái niệm đối tượng giả mạo, tôi biết rất nhiều người cảm thấy đó là điều phải. Câu hỏi đặt ra là tất cả các khuôn khổ giả mạo có thể cắm vào phiên bản TDD (MSTEST) của studio trực quan không?

Tôi đã khuyên quản lý rằng có lẽ chúng tôi chỉ nên thêm thử nghiệm hồi quy trong tương lai (phát triển mới hoặc lỗi tìm thấy) nhưng không cố gắng xem xét toàn bộ mã của chúng tôi và đưa vào kiểm tra đơn vị. Nó sẽ là quá lớn của dự án.

Dù sao, tôi sẽ đánh giá cao sự giúp đỡ của bất kỳ ai.

Answer 1

Điều đầu tiên phải làm là có được cuốn sách này:

Working Effectively with Legacy Code

Đối với một dự án lớn như vậy, đọc nó và nội hóa nó. TDD trên một ứng dụng hướng dữ liệu là đủ cứng. Trên di sản bạn cần một số kế hoạch và nỗ lực nghiêm túc. Đáng giá trong quan điểm của tôi, nhưng nó vẫn là một đường cong lớn.

Answer 2

1) Tôi sử dụng TestDriven.Net, và tôi thích nó vì vậy một 1 từ tôi cho rằng
2) Mã bảo hiểm là hữu ích, khi nghĩ về trong khung bên phải của tâm trí:
đang cao vùng phủ sóng không không nhất thiết có nghĩa là thử nghiệm đơn vị chất lượng cao, nhưng ...
Kiểm tra đơn vị chất lượng cao có nghĩa là mã vùng cao

Tôi chỉ sử dụng NCover, vì vậy không thể đề xuất các lựa chọn thay thế.

Về chế nhạo - một khi bạn nắm bắt được nội dung và ý nghĩa của nó đối với bạn, bạn sẽ thấy những lợi ích mà nó cung cấp. Cụ thể, điều đó có nghĩa là bạn không phụ thuộc vào việc tích hợp mã mà bạn đang thử nghiệm với sự phụ thuộc bên ngoài và cũng giúp giảm thời gian thực thi văn bản (ví dụ: giả mạo lớp truy cập dữ liệu của bạn ngăn sự tương tác tốn kém với DB). Đó là một yếu tố quan trọng trong quan điểm của tôi như là nếu các bài kiểm tra mất một thời gian dài để chạy, mọi người có thể bắt đầu không bận tâm chạy chúng nếu nó có nghĩa là họ phải chờ đợi quá lâu! Tôi sử dụng NUnit, trong đó có hỗ trợ cho mocks được xây dựng trong.

Buộc phương pháp tiếp cận TDD vào môi trường tích hợp liên tục (ví dụ: CruiseControl.NET) và bạn có thiết lập rất mạnh mẽ và hiệu quả.

Khi bắt đầu thử nghiệm TDD/đơn vị, tôi luôn khuyên bạn nên viết các bài kiểm tra mã được viết từ "bây giờ" trở đi và không tập trung quá nhiều vào việc viết bài kiểm tra cho mã cũ/hiện có. Đó là rất nhiều khó khăn hơn để làm nói chung và rất nhiều tốn kém thời gian khôn ngoan, đặc biệt là nếu mã cũ/không tươi trong tâm trí của bất cứ ai!

Cập nhật: Để giải thích điểm cuối cùng của tôi thêm một chút, để phản ứng lại lời nhận xét của Robert ...

Khi bạn đang cố gắng đứng dậy và chạy thử nghiệm với TDD/đơn vị, và đạt được đà với toàn bộ nhóm, bạn muốn điều đó là tích cực và hiệu quả nhất có thể. Các bài kiểm tra viết cho mã cũ không bị thay đổi trong giai đoạn ban đầu này đắt hơn so với mã mới vì mã không phải là mới, những phức tạp chính xác của nó nhiều khả năng phải được làm lại và không nhất thiết phải do lập trình viên ban đầu. Thêm vào đó, bạn có thể thấy khó để biện minh cho doanh nghiệp, thời gian cần thiết để xem xét lại mã cũ để viết kiểm tra cho họ, thay vì làm việc với chức năng mới/sửa lỗi/vấn đề thực.

Nó có thể trở thành một kinh nghiệm tiêu cực - một nhà phát triển có nhiệm vụ viết các bài kiểm tra cho mã cũ mà anh ấy biết/nhớ rất ít về việc sẽ khó hơn và do đó trải nghiệm đầu tiên của họ không phải là một trải nghiệm tích cực. Bạn cũng cần phải cẩn thận trong tình huống này vì bạn có thể kết thúc với các bài kiểm tra yếu, điều này mang lại cho bạn sự tự tin sai lầm. Theo kinh nghiệm của tôi, nó hoàn toàn quan trọng là mọi người đều có một khởi đầu tích cực với điều này, sự tự tin/động lực khác trong nó mất dần và kết quả cuối cùng là tồi tệ hơn nhiều.

Tôi là không thực sự nói bạn không nên thêm kiểm tra cho mã cũ - tôi tự làm khi tôi làm việc trong hoặc xung quanh mã cũ không có bất kỳ kiểm tra nào để từng bit một, cải thiện kiểm tra phạm vi và chất lượng. Sự khác biệt là, tôi đã tham gia vào quá trình này, một "người tin tưởng". Đó là giai đoạn đầu của nó, đó là chìa khóa ...do đó, quan điểm của tôi về việc không tập trung quá nhiều vào mã cũ khi bắt đầu.

Answer 3

Vâng, tôi muốn bắt đầu bằng cách đề xuất bạn nên mang công ty tư vấn biết TDD để giúp nhóm của bạn bắt đầu. Điều này đặc biệt quan trọng nếu bạn không có ai trong nhóm quen thuộc với TDD, thử nghiệm đơn vị, khung mocking, v.v. Tôi không chắc bạn mua được bao nhiêu từ quản lý hoặc nhóm, nhưng bạn không Tôi muốn nỗ lực đầu tiên của bạn thất bại, vì những sai lầm có thể đã bị ngăn cản bằng cách thuê một chuyên gia để giúp bạn thực hiện những bước đầu tiên đó.

Dù sao, tôi khuyên bạn nên bắt đầu nhỏ và chọn một dự án mới không quá lớn. Ngay cả một tập con nhỏ của một dự án lớn hơn cũng sẽ hoạt động. Sử dụng điều này như là một nơi để có được đội ngũ quen thuộc với TDD và để hiển thị quản lý rằng nó là khả thi. Sau đó, khi đội bóng thành thạo hơn, bạn có thể chọn tại các dự án lớn hơn. Đối với mã di sản tôi sẽ khuyên bạn nên nhìn vào cuốn sách này:

Làm việc hiệu quả với Legacy Mã, Michael Feathers

Ngoài ra tôi sẽ chắc chắn khuyên bạn nên nhìn vào cuốn sách này:

Art of Đơn vị kiểm tra, Roy Osherove

Nó có thể không phải là một cuốn sách TDD, nhưng nó là cuốn sách tuyệt vời để tìm hiểu về đơn vị thử nghiệm, mocking khuôn khổ, và nó thậm chí có một chương về mã di sản. Ngoài ra nó có một số khuyến nghị về cách để có được đội ngũ và quản lý mua in Nó nói một chút về TDD, kiểm tra tích hợp, tổ chức codebase của bạn, và rộng rãi về những gì làm cho một bài kiểm tra đơn vị tốt. Tất cả trong một đọc tuyệt vời.

Hy vọng điều này sẽ hữu ích.

Answer 4

100 ngón tay cái để làm việc hiệu quả với Mã kế thừa do Yishai đề xuất. Tôi cũng khuyên bạn nên Pragmatic Unit Testing in C# with NUnit khi bạn đang sử dụng .NET (mặc dù tôi giả sử C#). Nó rất hữu ích cho việc dạy những điều cơ bản về kiểm thử đơn vị, cung cấp một nền tảng vững chắc để làm việc.

Answer 5

Đừng vội vàng và vì Chúa không cố gắng buộc các nhà phát triển thực hiện TDD.

Nếu không - bạn sẽ nhận được 'thử nghiệm' chất lượng thấp lộn xộn, sẽ bị xóa sau vài tháng và nhà phát triển sẽ không bao giờ muốn nghe về TDD nữa.

Yêu cầu quan trọng nhất đối với TDD - tốt kiến ​​thức về cách viết kiểm tra (khá rõ ràng lý do).

Yêu cầu thứ hai - tốt kiến ​​thức về công nghệ đã sử dụng.
Đó là bởi vì nếu khó viết mã gì, việc thiết kế mã trong đầu sẽ là không thể.

Các công cụ đã qua sử dụng thực sự khá quan trọng.

P.s. tấn mã di sản và ứng dụng tập trung vào dữ liệu => một khuôn mẫu tốt cho thiên tai.

Answer 6

Trong một vài năm, tôi đã nhận thức và dabbled bằng văn bản kiểm tra đơn vị. Điều cho phép tôi thực sự tham gia vào thử nghiệm đơn vị là khi tôi bắt đầu làm việc trên một dự án nguồn mở với phạm vi kiểm tra ấn tượng. Nó thực sự đánh tôi rằng cách tôi viết phần mềm là 'ở phía bên trái của lịch sử'.

Bạn đã đề cập đến nhiều công cụ có khả năng được quảng cáo kích thích bạn và tự hỏi cách đặt chúng lại với nhau.Tôi nghĩ rằng những câu hỏi này được giải quyết rất tốt bởi "Các mẫu thử nghiệm xUnit", từ Addison-Wesley (http://xunitpatterns.com/). Cuốn sách này cho phép tôi tập hợp tất cả những công cụ và kỹ thuật mà tôi đã đọc trong quá khứ.

Cuốn sách này có thể phục vụ tốt hơn đối tượng người cũng đánh giá cao những cuốn sách khác như Mẫu thiết kế, Tái cấu trúc và Tái cấu trúc mẫu của Gang of Four thành Mẫu. Những cuốn sách này cũng rất tuyệt, mặc dù chúng không có sự thay đổi trực tiếp trong cách tôi viết mã sau khi đọc chúng. Việc trình bày các mẫu kiểm tra XUnit mặc dù phản ánh phong cách của các cuốn sách. Họ có thể khó đọc lúc đầu vì họ có xu hướng vượt qua các chương tham chiếu theo các hướng tùy ý. Tôi nghĩ chúng rất chắc chắn.

GoF trình bày các danh mục mẫu, tạo cấu trúc và hành vi. Các danh mục này đóng vai trò như một cách để liên kết và đối chiếu các mẫu đang được giải thích. Bằng cách kết hợp các mẫu thiết kế thử nghiệm với tuổi thọ điển hình của một thử nghiệm đơn vị, các mẫu Kiểm tra XUnit cũng dệt cùng một loạt các kỹ thuật có sẵn để thử nghiệm đơn vị. Các bước tương tự cũng được sử dụng để liên kết và tương phản các công cụ khác nhau được sử dụng để xây dựng các bài kiểm tra đơn vị.

Nó sẽ giúp với chế độ xem cấp cao và đi vào thực hiện thực tế.

Chỉ trích duy nhất của tôi về Mẫu kiểm tra XUnit là số lượng văn bản họ sử dụng để chỉ trích NUnit. NUnit là một phần tốt của chương trình, để tín dụng của tác giả NUNit chúng tôi đề cập đến như vậy nổi bật trong những gì tôi nghĩ rằng sẽ trở thành một cuốn sách kinh điển.

Answer 7

Để bắt đầu, tôi cũng khuyên bạn nên đọc Fowler's Refactoring. Chương đầu tiên cho cảm giác tốt về ý nghĩa của việc giới thiệu các bài kiểm tra sau đó giới thiệu một cách an toàn thay đổi (mặc dù nhấn mạnh ở đây là về thay đổi hành vi bảo tồn). Hơn nữa, nói chuyện this mô tả một số thực hành có thể giúp cải thiện khả năng kiểm tra mã của bạn. Misko Hevery cũng có this hướng dẫn viết mã có thể kiểm tra, tóm tắt bài nói chuyện.

Từ mô tả của bạn, có vẻ như bạn muốn kiểm tra các phần cốt lõi trong hệ thống của mình - các bộ phận có nhiều phụ thuộc thay đổi đáng sợ. Tùy thuộc vào mức độ truy cập dữ liệu được tách rời khỏi logic nghiệp vụ, bạn có thể cần phải cấu trúc lại về trạng thái mà mã dễ kiểm tra hơn - nơi dễ dàng và nhanh chóng để tạo các bộ dữ liệu thử nghiệm để xác minh logic trong sự cô lập . Đây có thể là một công việc lớn và có thể không đáng để thử nếu những thay đổi ở đây không thường xuyên và cơ sở mã được chứng minh tốt.

Lời khuyên của tôi sẽ là thực dụng và sử dụng trải nghiệm của nhóm để tìm các khu vực dễ dàng nhất để thêm các thử nghiệm có giá trị gia tăng. Tôi nghĩ rằng có nhiều bài kiểm tra đơn vị tập trung là cách tốt nhất để nâng cao chất lượng, nhưng có thể dễ dàng kiểm tra mã ở mức cao hơn bằng cách sử dụng các bài kiểm tra tích hợp hoặc kịch bản, chắc chắn ngay từ đầu. Bằng cách này, bạn có thể phát hiện các lỗi lớn trong các hệ thống cốt lõi của bạn sớm. Hãy rõ ràng về những gì các bài kiểm tra của bạn bao gồm. Kiểm tra kịch bản sẽ bao gồm rất nhiều mã, nhưng có lẽ sẽ không hiển thị các lỗi tinh vi.

Di chuyển từ SourceSafe sang Team System là một bước tiến lớn, mức độ lớn tùy thuộc vào số tiền bạn muốn thực hiện trong Hệ thống nhóm. Tôi nghĩ bạn có thể nhận được rất nhiều giá trị từ việc sử dụng khung công tác thử nghiệm tích hợp của Visual Studio. Ví dụ, như một bước đầu tiên bạn có thể thực hiện một số bộ thử nghiệm cơ bản cho các trường hợp sử dụng lõi/hệ thống cốt lõi. Các nhà phát triển có thể tự chạy chúng trong Visual Studio khi chúng hoạt động và trước khi đăng ký. Các bộ này có thể được mở rộng dần dần theo thời gian. Sau đó khi bạn nhận được TFS, bạn có thể xem xét việc chạy các bộ này khi đăng ký và là một phần của quá trình xây dựng tự động. Bạn có thể theo một con đường tương tự bất kể các công cụ cụ thể.

Hãy rõ ràng ngay từ đầu rằng có phí tổn trong việc duy trì mã kiểm tra và các thử nghiệm được thiết kế tốt có thể trả cổ tức. Tôi đã thấy các tình huống mà các bài kiểm tra được dán sao chép sau đó được chỉnh sửa một chút, v.v.Kiểm tra trùng lặp mã như thế này có thể dẫn đến sự bùng nổ về số dòng mã kiểm tra mà bạn cần duy trì khi thực hiện thay đổi mã sản phẩm nhỏ. Loại rắc rối này có thể làm xói mòn lợi ích của việc thử nghiệm.

Visual Studio 2008 sẽ chỉ hiển thị vùng phủ sóng của bạn, mặc dù phân tích mã cũng sẽ cung cấp các chỉ số khác như độ phức tạp chu trình trên mỗi assembly/class/method. Việc phủ sóng khối cao với các bài kiểm tra của bạn chắc chắn là quan trọng và cho phép bạn dễ dàng xác định các khu vực của hệ thống hoàn toàn không được kiểm tra.

Tuy nhiên, tôi nghĩ điều quan trọng cần nhớ là phạm vi bao phủ cao chỉ là một phép đo đơn giản về tính hiệu quả của các thử nghiệm của bạn. Ví dụ: giả sử bạn viết một lớp để dọn dẹp tệp lưu trữ và giữ lại 5 tệp mới nhất. Sau đó, bạn viết một trường hợp kiểm tra để kiểm tra xem bạn có bắt đầu với 10 tập tin sau đó chạy thanh tẩy bạn đang còn lại không 5. Việc thực hiện vượt qua bài kiểm tra có thể xóa các tệp mới nhất, nhưng có thể dễ dàng cung cấp 100% mức độ phù hợp. Thử nghiệm này chỉ xác minh 1 trong các yêu cầu.