2008-09-20 25 views
35
  • Giả sử chúng tôi đã nhận ra giá trị TDD quá muộn. Dự án đã trưởng thành, rất nhiều khách hàng đã bắt đầu sử dụng nó.
  • Nói kiểm tra tự động được sử dụng chủ yếu là thử nghiệm chức năng/hệ thống và có rất nhiều thử nghiệm GUI tự động.
  • Giả sử chúng tôi có yêu cầu tính năng mới và báo cáo lỗi mới (!). Quá trình phát triển tốt vẫn tiếp diễn.
  • Lưu ý rằng sẽ có rất nhiều đối tượng kinh doanh không có hoặc ít thử nghiệm đơn vị.
  • Quá nhiều sự cộng tác/mối quan hệ giữa chúng, một lần nữa chỉ được kiểm tra thông qua kiểm tra hệ thống/chức năng ở mức cao hơn. Không có thử nghiệm tích hợp cho mỗi se.
  • Cơ sở dữ liệu lớn tại chỗ với nhiều bảng, chế độ xem, v.v. Chỉ để khởi tạo một đối tượng kinh doanh duy nhất đã có rất nhiều chuyến đi vòng cơ sở dữ liệu.

Làm cách nào chúng tôi có thể giới thiệu TDD ở giai đoạn này?Có khả thi để giới thiệu Phát triển theo hướng thử nghiệm (TDD) trong một dự án trưởng thành không?

Mocking dường như là cách để đi. Nhưng số lượng chế nhạo chúng ta cần làm ở đây có vẻ như quá nhiều. Âm thanh như cơ sở hạ tầng phức tạp cần phải được phát triển cho hệ thống mocking làm việc cho các công cụ hiện có (BO, cơ sở dữ liệu, vv).

Điều đó có nghĩa là TDD là phương pháp phù hợp chỉ khi bắt đầu từ đầu? Tôi muốn nghe về các chiến lược khả thi để giới thiệu TDD trong một sản phẩm đã trưởng thành.

Trả lời

27

Tạo cơ sở hạ tầng giả mạo phức tạp có thể sẽ chỉ ẩn các sự cố trong mã của bạn. Tôi khuyên bạn nên bắt đầu với các bài kiểm tra tích hợp, với một cơ sở dữ liệu thử nghiệm, xung quanh các khu vực của cơ sở mã mà bạn dự định thay đổi. Khi bạn có đủ kiểm tra để đảm bảo rằng bạn sẽ không phá vỡ bất cứ điều gì nếu bạn thực hiện thay đổi, bạn có thể bắt đầu cấu trúc lại mã để làm cho nó dễ kiểm tra hơn.

Se cũng Michael Feathers xuất sắc cuốn sách Working effectively with legacy code, nó phải đọc cho bất cứ ai nghĩ đến việc giới thiệu TDD vào một cơ sở mã di sản.

+0

Cảm ơn đề xuất sách. Có vẻ như đó là những gì tôi tìm kiếm. – rpattabi

3

Có thể. Đừng làm tất cả cùng một lúc, nhưng chỉ giới thiệu những gì bạn cần để kiểm tra một mô-đun bất cứ khi nào bạn chạm vào nó.

Bạn cũng có thể bắt đầu với các bài kiểm tra chấp nhận mức cao hơn và làm việc theo cách của bạn từ đó (xem Fitnesse cho việc này).

16

Tôi nghĩ hoàn toàn khả thi khi giới thiệu TDD vào một ứng dụng hiện có, trên thực tế tôi đã tự làm nó gần đây.

Cách dễ nhất để mã chức năng mới theo cách TDD và cấu trúc lại mã hiện có để phù hợp với điều này. Bằng cách này, bạn bắt đầu với một phần nhỏ của mã của bạn được thử nghiệm nhưng các hiệu ứng bắt đầu lan truyền qua toàn bộ cơ sở mã.

Nếu bạn gặp lỗi, hãy viết một bài kiểm tra đơn vị để tái tạo nó, tái cấu trúc mã khi cần thiết (trừ khi nỗ lực thực sự không đáng).

Cá nhân, tôi không nghĩ rằng có bất kỳ nhu cầu phát điên và thử và trang bị thêm các bài kiểm tra vào hệ thống hiện tại vì điều đó có thể rất tẻ nhạt mà không có nhiều lợi ích.

Tóm lại, bắt đầu nhỏ và dự án của bạn sẽ trở nên ngày càng nhiều thử nghiệm bị nhiễm.

+0

Viết các bài kiểm tra đơn vị mới xung quanh các lỗi hoạt động tốt. Bạn không có bộ kiểm tra "hoàn chỉnh", nhưng bạn có thứ để xây dựng. –

9

Có thể.Từ mô tả của bạn, dự án có hình dạng tốt - số lượng tự động kiểm tra chức năng tự động hóa là một cách để đi! Trong một số khía cạnh của nó thậm chí còn hữu ích hơn so với thử nghiệm đơn vị. Hãy nhớ rằng TDD! = Kiểm tra đơn vị, đó là tất cả về lặp lại ngắn và tiêu chí chấp nhận vững chắc.

Hãy nhớ rằng việc có dự án hiện tại và được chấp nhận thực sự làm cho việc thử nghiệm dễ dàng hơn - ứng dụng hoạt động là đặc điểm kỹ thuật yêu cầu tốt nhất. Vì vậy, bạn đang ở trong một vị trí tốt hơn so với một người chỉ có một mẩu giấy để làm việc với.

Chỉ cần bắt đầu thực hiện các yêu cầu/sửa lỗi mới của bạn với TDD. Hãy nhớ rằng sẽ có một chi phí liên quan đến việc chuyển đổi phương pháp (đảm bảo khách hàng của bạn biết điều này!) Và có thể mong đợi một sự miễn cưỡng tốt từ các thành viên trong nhóm, những người quen với 'những cách thức tốt đẹp'.

Không chạm vào những thứ cũ trừ khi bạn cần. Nếu bạn sẽ có yêu cầu nâng cao sẽ ảnh hưởng đến nội dung hiện có thì hãy thêm thời gian để thực hiện các công việc phụ.

Riêng tôi không thấy nhiều giá trị trong việc giới thiệu một cơ sở hạ tầng phức tạp cho giả-up - chắc chắn có một cách để đạt được kết quả tương tự trong một chế độ nhẹ nhưng nó rõ ràng là phụ thuộc vào hoàn cảnh của bạn

+1

+1 cho "TTD! = Unit testing", bây giờ tôi sẽ sửa lỗi đánh máy đó. – Johnsyweb

2

Tôi sẽ bắt đầu với một số thử nghiệm tích hợp cơ bản. Điều này sẽ nhận được mua từ các nhân viên còn lại. Sau đó, bắt đầu để tách các phần của mã của bạn có phụ thuộc. Làm việc theo hướng sử dụng Dependency Injection vì nó sẽ làm cho mã của bạn dễ kiểm tra hơn nhiều. Hãy coi lỗi là cơ hội để viết mã có thể kiểm tra.

5

Một công cụ có thể giúp bạn thử nghiệm mã cũ (giả sử bạn không thể \ không có thời gian để cấu trúc lại nó, là Typemock Isolator: Typemock.com Nó cho phép tiêm phụ thuộc vào mã hiện có mà không cần phải trích xuất giao diện và vì nó không sử dụng các kỹ thuật phản chiếu tiêu chuẩn (proxy động vv ..) nhưng sử dụng các API profiler thay vì Nó được sử dụng để kiểm tra các ứng dụng dựa trên SharePoint, SharePoint và các khu vực có vấn đề khác. (Tôi làm việc như một nhà phát triển trong công ty đó, nhưng đó là công cụ duy nhất không buộc bạn phải cấu trúc lại mã cũ, tiết kiệm thời gian và tiền bạc) Tôi cũng khuyên bạn nên "Làm việc hiệu quả với mã cũ" để biết thêm các kỹ thuật .

Roy

Các vấn đề liên quan