Tôi có nên bắt đầu với thử nghiệm Đơn vị khi dạy một nhà phát triển mới không?

Question

Tôi hiện đang làm việc trên một dự án đang sử dụng các công nghệ như Silverlight, WCF, EnterpriseLibrary, Unity, LinqToSql, NUnit, RhinoMocks trong .Net 3.5

Tôi đang đào tạo một nhà phát triển mới có kinh nghiệm với VB tập lệnh và SQL, nhưng không có sự tiếp xúc nào .Net

Gần như 100% của codebase có phạm vi kiểm thử đơn vị, nhưng dường như việc bắt đầu viết các bài kiểm tra đơn vị là quá nhiều, có đủ thứ có được đầu của mình xung quanh, mà không có sự nhầm lẫn thêm của các bài kiểm tra đơn vị và mocks.

Anh ấy được giao nhiệm vụ triển khai các tính năng mới cho giải pháp cắt qua từng lớp, từ giao diện người dùng đến cơ sở dữ liệu và luôn có nhu cầu mạnh mẽ để đưa tính năng vào sản xuất càng sớm càng tốt.

Bạn nghĩ cách tiếp cận tốt nhất là gì để giúp một người nào đó tăng tốc?

Answer 1

Với hoàn toàn không có kinh nghiệm .NET, tôi muốn nói gói đầu của bạn xung quanh TDD cùng một lúc như học tập .NET là một chút nhiều.

Một số người có nhiều trải nghiệm .NET có đủ thời gian với TDD - nó đòi hỏi một sự thay đổi thực sự trong cách tiếp cận cơ bản để phát triển. Đi từ VB đến .NET không khó nhưng phải mất thời gian.

Bạn thực sự muốn tránh nhầm lẫn - TDD là cách tốt cách phát triển, nhưng không phải là cách phát triển và TDD! = .NET. Trong thực tế, nó hoàn toàn trực giao - cố gắng dạy một phương pháp mới và một nền tảng mới cùng một lúc? Tôi không thể thấy đó là một ý tưởng hay.

Answer 2

Có vẻ như nhà phát triển mới đã trải qua thử nghiệm do hỏa hoạn.

Có vẻ như bạn nên để anh ấy bắt kịp tốc độ và bắt đầu chia sẻ các tính năng, cho anh ấy thời gian làm việc và khi anh ấy thoải mái ... thì hãy bắt đầu anh ấy trong Bài kiểm tra đơn vị.

Answer 3

Xem xét đã có rất nhiều điều cần tìm hiểu, tôi sợ nói về TDD và thử nghiệm tự động có thể hơi "quá nhiều": nếu người phát triển mới của bạn không biết cách phát triển, anh ấy sẽ không biết làm thế nào để phát triển các bài kiểm tra - và các bài kiểm tra mà anh ta sẽ viết có lẽ sẽ không thực sự hữu ích.

Trong trường hợp của bạn, tôi cho phép anh ấy viết mã cho một vài ngày/tuần, thử nghiệm bằng tay; và khi anh ấy bắt đầu hiểu codebase của bạn, tôi dành chút thời gian với anh ấy, cho một số lập trình đôi: đây sẽ là dịp tuyệt vời để giới thiệu thử nghiệm tự động và xem lại mã/nhận xét/cải thiện cùng một lúc.

Answer 4

Tôi sẽ nói có - toàn bộ điểm kiểm tra là tập trung ở một khu vực. Nó thực sự giúp làm sạch đầu và nó không giống như phải mất hơn 10 phút để học NUnit. Chắc chắn anh ta có lẽ sẽ đấu tranh một chút với các khái niệm trong một thời gian nhưng một chút công việc khó khăn và rất nhiều cặp nên vượt qua dễ dàng hơn rất nhiều so với ném anh ta chỉ định mà không có sự hướng dẫn mà TDD cung cấp.

Answer 5

Tôi sẽ nói bắt đầu lập trình viên hỗ trợ. Hiểu được vấn đề người dùng và tìm kiếm lỗi, tìm lỗi và sửa lỗi sẽ dạy cho các lập trình viên mới cách ứng dụng được đặt lại với nhau, viết các bài kiểm tra là nhiều hơn về phát triển mới.

Answer 6

Nếu bạn có sự nhạo báng nặng nề trong Khu vực thử nghiệm, bạn sẽ gặp phải các vấn đề nghiêm trọng để hiểu điều đó.Tuy nhiên, nếu bạn chỉ định Nhiệm vụ đơn giản hơn (nơi anh ta sẽ không phải quan tâm đến Mockery) và tìm hiểu để tìm hiểu "mã của tôi nên làm gì?" điều này có thể thực hiện được.

Answer 7

Để một nhà phát triển thiếu kinh nghiệm, kiểm tra đơn vị trông giống như tăng gấp đôi tất cả mã của bạn. Đó là một tắt rất lớn.

Bạn thực sự cần phải để họ thất bại trước khi họ thực sự có thể đánh giá cao lợi ích của thử nghiệm đơn vị.

Answer 8

Nếu đó là tôi, tôi sẽ ghép nối với anh ấy và TDD một chút. Bạn viết một số bài kiểm tra, ông viết mã mà làm cho nó hoạt động sau đó ông viết bài kiểm tra tiếp theo và bạn viết mã để làm cho nó hoạt động, v.v.

Vui vẻ, giúp bạn trải nghiệm nhanh chóng, tiết kiệm thời gian và tiền bạc.

Answer 9

Tôi sẽ bắt đầu đơn giản - cắt nhiệm vụ thành các phần hợp lý, sau đó ghép nối với anh ta cho đến khi anh ta nắm được phần hiện tại. Tôi không nghĩ rằng một sự thâm nhập hoàn toàn vào TDD sẽ có hiệu quả cho đến khi đạt được một mức độ thoải mái cao về phía anh ấy, nhưng điều đó không có nghĩa là bạn không thể tiếp xúc với anh ta để thử nghiệm đơn vị và như vậy.

Có lẽ, như một phần công việc chuẩn bị của bạn, bạn có thể viết một vài bài kiểm tra cần thiết để hoàn thành nhiệm vụ được giao. Khi ông đang làm việc thông qua vấn đề này, bạn có thể hướng dẫn anh ta về một giải pháp chung, sử dụng các bài kiểm tra ("ánh sáng đỏ BAD!") Để chứng minh nơi mà suy nghĩ của mình là tắt.

Từ đó, bạn có thể "lái xe" trong khi "điều hướng" - anh ấy xác định chức năng mong muốn cho bạn và bạn có thể đặt câu hỏi về cách bạn có thể kiểm tra chức năng đó. Bắt đầu viết các bài kiểm tra với anh ta để anh ta có thể thấy kết nối giữa các bài kiểm tra và sản phẩm, sau đó để anh ta từ từ tiếp quản. Hy vọng rằng, nếu anh ấy thích hợp, anh ấy sẽ có thể nắm bắt các khái niệm từ đầu, sau đó khấu trừ cách viết các bài kiểm tra của riêng mình (với hướng dẫn của bạn, tất nhiên!). Bước cuối cùng tôi nghĩ là ném anh ta vào hồ bơi và buộc anh ấy viết các bài kiểm tra như một phần của việc xác định chức năng anh ấy muốn viết.

Nó có lẽ sẽ không phải là một quá trình nhanh chóng, nhưng hy vọng điều này sẽ cho anh ta một nền tảng tốt trong thử nghiệm TDD/đơn vị

Answer 10

Ông được phân công với các nhiệm vụ để thực hiện tính năng mới cho các giải pháp rằng cắt qua từng lớp, từ giao diện người dùng đến cơ sở dữ liệu và luôn có nhu cầu khách hàng mạnh mẽ để yêu cầu tính năng sản xuất ngay sau .

Bạn nghĩ cách tiếp cận nào tốt nhất sẽ giúp người khác có được tốc độ tối đa là ?

Nếu bạn có thông tin không bán thì có thể không bao giờ tăng tốc. Hãy dạy cho anh ta cách bạn sẽ thực hiện công việc.

Là thành viên cơ sở của nhóm, "nhu cầu khách hàng mạnh" (tức là vấn đề với lịch biểu) không phải là vấn đề của mình: đó là điều mà trưởng nhóm và/hoặc người quản lý dự án nên tạm trú.

Bạn có thể cần phải giáo dục khách hàng: mang lại thành viên nhóm mới không có kinh nghiệm trước đó với công nghệ là đầu tư đáng giá trong dài hạn.

Trong ngắn hạn bạn (hoặc khách hàng thay thế) có thể thấy ít hoặc không có lợi ích ngay lập tức: bởi vì anh ấy chậm (học) và dành một chút thời gian của bạn (không độc lập).

IMO bạn nên:

• Không làm cho anh ta vội (thay vì để cho anh ta học cách làm điều đó trước khi bạn hy vọng anh ta làm điều đó một cách nhanh chóng)

• Tập trung vào bất cứ điều gì là cần thiết để đảm bảo rằng mình đầu ra không làm suy giảm chất lượng tổng thể của các phân phôi của dự án (nghĩa là bạn chắc chắn nên dạy cho anh ta, và đảm bảo rằng lịch trình của anh ta cho phép, bất cứ phương pháp kiểm tra nhà phát triển và chất lượng nào mà bạn mong đợi của các nhà phát triển)

Điều đó nói rằng, I don't think that unit test are always necessary. Nhưng trong một tình huống mà đó là một lập trình viên mới (không có kinh nghiệm), và, nơi bạn đã rõ ràng đã quyết định rằng phạm vi kiểm tra đơn vị 100% là điều đúng cho dự án này, tôi thấy khó hiểu tại sao bạn lại nghĩ đến thay đổi quá trình phát triển của bạn ngay bây giờ cho anh ta (trừ khi có lẽ những tính năng này mà anh ta được chỉ định có một số yêu cầu về lịch trình/chất lượng khác với các tính năng khác).

Answer 11

Nếu không phải bây giờ thì khi nào? Tôi nghĩ dòng suy luận mà tôi đang thấy trong cuộc thảo luận này là một cái cớ để không làm bài kiểm tra đơn vị. Sẽ luôn có một lập trình viên giỏi hơn tôi, tôi sẽ luôn là một lập trình viên tốt hơn vào ngày mai.

Thậm chí gợi ý rằng "chỉ các nhà phát triển ninja uber" nên kiểm tra đơn vị là thông báo sai để gửi, đặc biệt nếu bạn đánh giá 100% số liệu thống kê mức độ phù hợp của mình.

Kiểm tra đơn vị dạy một API của mã đang được kiểm tra ngược lại và tiến lên mà không làm cho nhà phát triển tìm hiểu bằng cách thực hiện các thay đổi chưa được kiểm chứng nguy hiểm đối với mã sản xuất.

Đối với vấn đề phức tạp-- mã phức tạp là mã phức tạp. Sự phát triển cao bồi mà không có bài kiểm tra đơn vị không làm cho nó đơn giản hơn.

Answer 12

để người khác viết các bài kiểm tra đơn vị và yêu cầu anh ấy viết mã để vượt qua bài kiểm tra. Một khi anh ấy cảm thấy thoải mái với điều đó, bạn có thể giới thiệu anh ta để tạo ra các bài kiểm tra.

Answer 13

gì tôi sẽ làm là nói:

"Chúng tôi sử dụng TDD ở đây, mà bạn sẽ làm là tốt, nhưng trước tiên tôi muốn bạn để có được thoải mái với môi trường .NET Sau đó, trong một vài tuần chúng tôi. sẽ ngồi xuống và viết mã một vài bài kiểm tra đơn vị với nhau. "

Tôi nghĩ điều này cho anh ta thời gian để tiêu hóa.