Triển khai thử nghiệm đơn vị tại một công ty không làm điều đó

Trưởng bộ phận phát triển phần mềm của công ty tôi chỉ "từ chức" (nghĩa là bị sa thải) và chúng tôi hiện đang xem xét cải thiện các hoạt động phát triển tại công ty của chúng tôi. Chúng tôi muốn triển khai thử nghiệm đơn vị trong tất cả các phần mềm được tạo từ đây trở đi.

Phản hồi từ các nhà phát triển là thế này:

• Chúng tôi biết kiểm tra là có giá trị
• Nhưng, bạn luôn thay đổi thông số kỹ thuật nên sẽ lãng phí thời gian
• Và, thời hạn của bạn rất chặt chẽ, chúng tôi không có đủ thời gian để kiểm tra

Phản hồi từ CEO là đây:

• Tôi muốn công ty chúng tôi thử nghiệm tự động, nhưng tôi không biết làm thế nào để nó xảy ra
• Chúng tôi không có thời gian để viết tài liệu đặc điểm kỹ thuật lớn

Làm thế nào để các nhà phát triển có được thông số kỹ thuật bây giờ? Truyền miệng hoặc slide PowerPoint. Rõ ràng, đó là một vấn đề lớn. Đề nghị của tôi là thế này:

• Chúng ta cũng cung cấp cho các nhà phát triển một tập hợp dữ liệu thử nghiệm và kiểm tra đơn vị
• Đó là thông số kỹ thuật. Quản lý phải rõ ràng và định lượng về những gì nó muốn.
• Các nhà phát triển có thể đặt nó bất kỳ chức năng nào khác mà họ cảm thấy cần thiết và nó không cần phải được kiểm tra

Chà, nếu bạn đã từng ở một công ty trong tình huống này, bạn đã giải quyết vấn đề như thế nào? Liệu cách tiếp cận này có vẻ hợp lý?

Có vẻ như bạn đang trộn lẫn hai loại thử nghiệm khác nhau: thử nghiệm đơn vị và thử nghiệm hệ thống / chấp nhận . Cái trước hoạt động ở mức thấp hơn, kiểm tra các đoạn mã nhỏ (thường là các phương thức riêng lẻ), thường nằm sâu bên trong chương trình, không hiển thị trực tiếp cho người dùng. Cái sau kiểm tra toàn bộ chương trình mà người dùng của nó nhìn thấy, ở mức độ chi tiết cao hơn nhiều. Vì vậy, chỉ có cái sau có thể dựa trên bất kỳ hình thức đặc tả hệ thống nào.

Việc tách rời hai vấn đề giúp dễ dàng bắt đầu tiến tới một quá trình phát triển được cải thiện. Bắt đầu viết bài kiểm tra đơn vị càng sớm càng tốt , bất kể phần mềm (không) được chỉ định ở mức cao như thế nào. Bất cứ khi nào một nhà phát triển tạo ra hoặc thay đổi một phương thức, nó sẽ thực hiện một cái gì đó cụ thể, có thể (và nên) được kiểm tra đơn vị. Theo kinh nghiệm của tôi, ngay cả việc thay đổi các yêu cầu cấp cao thường không ảnh hưởng đáng kể đến các khối mã cấp thấp hơn này: mã chủ yếu cần được sắp xếp lại, thay vì vứt bỏ hoặc viết lại hoàn toàn. Do đó, hầu hết các bài kiểm tra đơn vị hiện tại sẽ tiếp tục chạy tốt.

Một điều kiện quan trọng để cho phép thử nghiệm đơn vị là: thời hạn không nên được quyết định bởi ban quản lý, mà thay vào đó nên dựa trên ước tính công việc của các nhà phát triển (người này nên đưa vào ước tính thời gian cần thiết để viết thử nghiệm đơn vị phù hợp). Hoặc, nếu thời hạn được ấn định, phạm vi giao hàng sẽ được thương lượng. Không có số lượng quản lý (mis) nào có thể thay đổi sự thật cơ bản rằng một số nhà phát triển nhất định chỉ có thể cung cấp một lượng công việc chất lượng nhất định trong một khoảng thời gian nhất định.

Song song với điều này, hãy bắt đầu thảo luận về cách tốt nhất để làm rõ và ghi lại các yêu cầu và biến chúng thành các bài kiểm tra chấp nhận mức cao. Đây là một quá trình tinh luyện liên tiếp dài hơn, có thể dễ dàng mất nhiều năm để có được trạng thái ổn định, tốt hơn trong toàn bộ tổ chức. Một điều có vẻ khá chắc chắn từ mô tả của bạn: cố gắng khắc phục các yêu cầu thay đổi liên tục bằng cách viết các tài liệu đặc tả kỹ thuật lớn lên phía trước chỉ là không hoạt động . Thay vào đó, nên tiến tới một cách tiếp cận nhanh nhẹn hơn, với các bản phát hành và trình diễn phần mềm thường xuyên cho người dùng và rất nhiều cuộc thảo luận về những gì họ thực sự muốn. Người dùng có quyền thay đổi suy nghĩ của mình về các yêu cầu bất cứ lúc nào - tuy nhiên, mỗi thay đổi có chi phí của nó (về thời gian và tiền bạc). Các nhà phát triển có thể ước tính chi phí cho mỗi yêu cầu thay đổi, từ đó cho phép người dùng / chủ sở hữu sản phẩm đưa ra quyết định sáng suốt. "Chắc chắn, sự thay đổi tính năng này sẽ rất tốt ... nhưng nếu nó trì hoãn việc phát hành tính năng quan trọng khác này và chi phí rất nhiều, hãy đưa nó vào tồn đọng ngay bây giờ".

Bắt người dùng xác định các trường hợp thử nghiệm chấp nhận và tạo dữ liệu thử nghiệm là một cách tuyệt vời để liên quan đến họ nhiều hơn và để tạo niềm tin lẫn nhau giữa người dùng và nhà phát triển. Điều này buộc cả hai bên phải tập trung vào các tiêu chí chấp nhận cụ thể, có thể đo lường được, có thể kiểm chứng và phải suy nghĩ các trường hợp sử dụng thông qua nhiều chi tiết hơn so với điển hình. Do đó, người dùng có thể kiểm tra trạng thái phát triển hiện tại trực tiếp với mỗi bản phát hành và nhà phát triển nhận được phản hồi đo lường cụ thể, rõ ràng hơn về tình trạng của dự án. Lưu ý rằng điều này đòi hỏi sự cam kết cao hơn từ người dùng và cách thức hoạt động mới, có thể là một điều khó khăn để chấp nhận và học hỏi.

Kinh nghiệm của tôi khi thực hiện quá trình chuyển đổi

Trong nhiều năm, tôi đã hiểu sai rằng tôi không có đủ thời gian để viết bài kiểm tra đơn vị cho mã của mình. Khi tôi viết bài kiểm tra, chúng là những thứ nặng nề, nặng nề, điều đó chỉ khuyến khích tôi nghĩ rằng tôi chỉ nên viết bài kiểm tra đơn vị khi tôi biết chúng là cần thiết.

Gần đây tôi đã được khuyến khích sử dụng Phát triển theo hướng thử nghiệm và tôi thấy đó là một tiết lộ hoàn chỉnh. Bây giờ tôi tin chắc rằng tôi không có thời gian để không viết bài kiểm tra đơn vị .

Theo kinh nghiệm của tôi, bằng cách phát triển với thử nghiệm trong tâm trí, bạn kết thúc với các giao diện sạch hơn, các lớp và mô-đun tập trung hơn và nói chung là RẮN hơn , mã có thể kiểm tra.

Mỗi lần tôi làm việc với mã kế thừa không có kiểm tra đơn vị và phải kiểm tra thủ công một cái gì đó, tôi cứ nghĩ "việc này sẽ nhanh hơn rất nhiều nếu mã này đã có kiểm tra đơn vị". Mỗi lần tôi phải thử và thêm chức năng kiểm tra đơn vị vào mã có độ khớp cao, tôi cứ nghĩ "việc này sẽ dễ dàng hơn nhiều nếu nó được viết theo cách tách rời".

So sánh và đối chiếu hai trạm thử nghiệm mà tôi hỗ trợ. Một cái đã xuất hiện được một thời gian và có rất nhiều mã kế thừa, trong khi cái còn lại thì tương đối mới.

Khi thêm chức năng vào phòng thí nghiệm cũ, thường là trường hợp xuống phòng thí nghiệm và dành nhiều giờ để làm việc với hàm ý của chức năng họ cần và làm thế nào tôi có thể thêm chức năng đó mà không ảnh hưởng đến bất kỳ chức năng nào khác. Mã đơn giản là không được thiết lập để cho phép thử nghiệm ngoại tuyến, do đó, hầu hết mọi thứ phải được phát triển trực tuyến. Nếu tôi đã cố gắng phát triển ngoại tuyến thì tôi sẽ kết thúc với nhiều đối tượng giả hơn là hợp lý.

Trong phòng thí nghiệm mới hơn, tôi thường có thể thêm chức năng bằng cách phát triển ngoại tuyến tại bàn của mình, chỉ loại bỏ những thứ cần thiết ngay lập tức, và sau đó chỉ dành một thời gian ngắn trong phòng thí nghiệm, loại bỏ mọi vấn đề còn lại không được xử lý -hàng.

Lời khuyên của tôi

Có vẻ như bạn đã khởi đầu tốt, bất cứ khi nào bạn sẽ tạo ra những thay đổi lớn cho quy trình phát triển của mình, bạn phải chắc chắn rằng mọi người đều tham gia vào việc đưa ra quyết định đó, và lý tưởng nhất là hầu hết mọi người đã mua nó. Từ câu hỏi của bạn, có vẻ như bạn đã hiểu đúng. Nếu mọi người không nhiệt tình với ý tưởng này, thì chắc chắn sẽ thất bại hoặc tạo ra ý chí xấu.

Trừ khi bạn có thể trình bày một trường hợp kinh doanh hấp dẫn, tôi sẽ không đề xuất triển khai các bài kiểm tra đơn vị và thông số kỹ thuật cho toàn bộ hệ thống của bạn. Như tôi đã đề cập ở trên, nếu một hệ thống không được thiết kế để kiểm tra, có thể rất khó để viết các bài kiểm tra tự động cho nó.

Thay vào đó, tôi khuyên bạn nên bắt đầu nhỏ và sử dụng Quy tắc Hướng đạo nam :

Luôn luôn để khu cắm trại sạch hơn bạn tìm thấy.

Nếu trong khi bạn đang triển khai một cái gì đó trên cơ sở mã này, bạn có thể xác định các thử nghiệm cụ thể cần có để kiểm tra hành vi hiện có và chuyển từ hành vi cũ sang hành vi mới, thì bạn đã ghi lại sự thay đổi trong thông số kỹ thuật và bắt đầu thực hiện các thử nghiệm đơn vị cho hệ thống của bạn.

Các mô-đun mà bạn không chạm vào sẽ không được kiểm tra đơn vị, nhưng nếu bạn không chạm vào chúng thì có thể là do chúng đã được kiểm tra kỹ lưỡng trong sử dụng và không cần thay đổi, hoặc chúng không bao giờ được sử dụng.

Những gì bạn muốn tránh là lãng phí toàn bộ khối lượng nỗ lực viết bài kiểm tra không cần thiết ( YAGNI cũng hoạt động tốt đối với mã kiểm tra như mã sản xuất * 8 '), sẽ không bao giờ được sử dụng lại và làm mất tinh thần mọi người vào nghĩ rằng xét nghiệm là vô ích sau khi tất cả.

Tóm lược

Bắt đầu nhỏ, xây dựng niềm tin trong các bài kiểm tra tăng dần và đạt được giá trị kinh doanh từ việc phát triển các bài kiểm tra khi nào và ở đâu chúng có lợi nhất cho nhóm của bạn.

Điều đầu tiên cần làm là không tập trung vào kiểm tra, mà là làm cho quá trình tổng thể trở nên đúng đắn. Không có điểm kiểm tra bất cứ điều gì nếu bạn không hiểu đầy đủ những gì nó phải làm!

Vì vậy, .. thông số kỹ thuật đầu tiên và thông số kỹ thuật tài liệu không thay đổi (tốt, không phải ngay lập tức). Bạn phải nhìn vào làm cho những người thực hiện. Tôi muốn giới thiệu một trang web nơi người dùng có thể tải lên thông số kỹ thuật hoặc nhập chúng trực tiếp. Bạn cũng có thể liên kết nó với một trình theo dõi lỗi và hướng dẫn về tiến trình của dự án.

Rất có thể, đó là tất cả những gì bạn thực sự cần. Bạn có thể thêm kiểm thử đơn vị vào nội bộ đó và quản lý không bao giờ cần biết rằng các nhà phát triển đang thực hiện kiểm tra đơn vị. Theo một cách nào đó, đó là cách nó được coi là.

Bạn vẫn sẽ cần phải kiểm tra hệ thống, nhưng cũng có thể được liên kết với trang web quản lý dự án, sau khi được phát hành, nhóm thử nghiệm (ngay cả khi đó là một nhà phát triển may mắn khác đang quay vòng) có thể cập nhật nó với các thử nghiệm mà họ đã sử dụng để xem toàn bộ treo cùng nhau.

Tôi thực sự không nghĩ rằng điều này sẽ thay đổi chỉ sau một đêm, nếu bạn đã quen với thông số kỹ thuật 'truyền miệng', thì trận chiến gần như sẽ thay đổi hoàn toàn hành vi này - và bạn sẽ chống lại điều này. Một người dùng (hoặc BA hoặc PM hoặc bất cứ ai) đã từng nói "chỉ cần làm cho nó x" và bây giờ cần viết tất cả sẽ không phản hồi tốt, rất có thể họ sẽ viết tài liệu cụ thể mơ hồ và sau đó làm rõ chúng với những cập nhật truyền miệng. Vì vậy, hãy quên thử nghiệm đơn vị và bắt đầu với vấn đề lớn mà bạn gặp phải với vòng đời phát triển.

Vấn đề đầu tiên: để "cung cấp cho các nhà phát triển một tập hợp dữ liệu thử nghiệm và kiểm tra đơn vị", trước tiên bạn phải viết các thử nghiệm đơn vị đó, đây là công việc của các nhà phát triển. Các thử nghiệm đơn vị không thay thế đặc điểm kỹ thuật: thông số kỹ thuật dự định có mức độ trừu tượng cao hơn các thử nghiệm đơn vị.

Vấn đề thứ hai: có vẻ như bạn muốn phạm vi kiểm tra đơn vị tối đa. Trong trường hợp này, vâng, sẽ tốn quá nhiều thời gian và tiền bạc để viết cả bài kiểm tra và mã trong bối cảnh mà các yêu cầu liên tục thay đổi. Thay vào đó, hãy quyết định phần nào của mã là quan trọng và đơn vị chỉ kiểm tra những phần đó. Trong nhiều trường hợp, các yêu cầu thay đổi không ảnh hưởng đến các bộ phận quan trọng của sản phẩm. Một khách hàng (hoặc CEO, hoặc bất cứ điều gì) thường yêu cầu di chuyển bảng điều khiển này sang bên phải hoặc thay đổi màu sắc của tiêu đề này từ màu đỏ sang màu xanh lá cây: những điều không ai quan tâm và không yêu cầu kiểm tra chuyên sâu. Mặt khác, khách hàng sẽ không bao giờ yêu cầu thay đổi thuật toán băm từ SHA512 sang SHA256 hoặc thay đổi cách bạn lưu trữ phiên, trong khi đó là những phần cần thử nghiệm nhiều nhất.