Một tên mới cho các bài kiểm tra đơn vị [đã đóng]

Tôi không bao giờ sử dụng để thích thử nghiệm đơn vị. Tôi luôn nghĩ rằng nó làm tăng số lượng công việc tôi phải làm.
Hóa ra, điều đó chỉ đúng về số lượng dòng mã thực tế bạn viết và hơn nữa, điều này hoàn toàn được bù đắp bằng sự gia tăng số lượng dòng mã hữu ích mà bạn có thể viết trong một giờ với các bài kiểm tra và phát triển theo hướng kiểm tra.

Bây giờ tôi yêu các bài kiểm tra đơn vị vì chúng cho phép tôi viết mã hữu ích, lần đầu tiên nó thường hoạt động! (gõ lên mặt gỗ)

Tôi đã thấy rằng mọi người không muốn làm các bài kiểm tra đơn vị hoặc bắt đầu một dự án với sự phát triển theo hướng kiểm tra nếu họ ở trong thời gian nghiêm ngặt hoặc trong một môi trường nơi những người khác không làm điều đó, vì vậy họ không làm. Kiểu như, một từ chối văn hóa thậm chí cố gắng.

Tôi nghĩ một trong những điều mạnh mẽ nhất về kiểm thử đơn vị là sự tự tin mà nó mang lại cho bạn để thực hiện tái cấu trúc. Nó cũng mang lại hy vọng mới, rằng tôi có thể đưa mã của mình cho người khác để cấu trúc lại / cải thiện và nếu thử nghiệm đơn vị của tôi vẫn hoạt động, tôi có thể sử dụng phiên bản mới của thư viện mà họ đã sửa đổi, khá nhiều, mà không sợ.

Đây là khía cạnh cuối cùng của thử nghiệm đơn vị mà tôi nghĩ cần một tên mới. Bài kiểm tra đơn vị giống như một hợp đồng về những gì mã này nên làm bây giờ và trong tương lai.
Khi tôi nghe thử nghiệm từ, tôi nghĩ về những con chuột trong lồng, với nhiều thí nghiệm được thực hiện trên chúng để thấy hiệu quả của một hợp chất. Đây không phải là thử nghiệm đơn vị, chúng tôi sẽ không thử các mã khác nhau để xem đâu là cách tiếp cận quan trọng nhất, chúng tôi đang xác định đầu ra nào chúng tôi mong đợi với đầu vào nào. Trong ví dụ về chuột, các thử nghiệm đơn vị giống như các định nghĩa về cách thức vũ trụ hoạt động trái ngược với các thí nghiệm được thực hiện trên chuột.

Tôi có bị bẻ khóa hay có ai khác thấy sự từ chối này để thử nghiệm không và họ có nghĩ rằng đó là một lý do tương tự mà họ không muốn làm điều đó không?
Những lý do nào khiến bạn / người khác đưa ra để không thử nghiệm?
Bạn nghĩ gì về động lực của họ không phải là thử nghiệm đơn vị?

Và như một tên mới cho thử nghiệm đơn vị có thể vượt qua một số phản đối, làm thế nào về jContract? (Tôi biết một chút về trung tâm Java :) hoặc Hợp đồng đơn vị?

Tôi có bị bẻ khóa hay có ai khác thấy sự từ chối này để thử nghiệm không và họ có nghĩ rằng đó là một lý do tương tự mà họ không muốn làm điều đó không?

Kiểm tra từ trong kiểm tra đơn vị làm cho mọi người nghĩ rằng đây là kiểm tra tích hợp hoặc kiểm tra giao diện người dùng vì đó là loại kiểm tra duy nhất họ từng thực hiện. Nó giống như đưa java vào javascript.

Khi một cái gì đó có một tên xấu và nó ảnh hưởng đến suy nghĩ của mọi người về nó, đó được gọi là lỗi đóng khung. Lỗi đóng khung có xu hướng hời hợt-- mọi người thông minh và có thể nhìn xuyên qua tất cả các loại tên xấu, ẩn dụ xấu.

Những lý do nào khiến bạn / người khác đưa ra để không thử nghiệm?

Phụ thuộc khó chế giễu / giả mạo /

Bạn nghĩ gì về động lực của họ không phải là thử nghiệm đơn vị?

Kiểm thử đơn vị có số lượng khái niệm khiêm tốn và khối lượng công việc không hề nhỏ cần phải được thực hiện trước khi người ta ngừng viết bài kiểm tra đơn vị xấu và bắt đầu viết bài kiểm tra tốt. Khi mọi người trở nên tốt hơn trong việc giải thích thử nghiệm đơn vị là gì, việc áp dụng sẽ tăng lên. Theo kinh nghiệm của tôi, thử nghiệm đơn vị có tác dụng gần như kỳ diệu đối với năng suất và chất lượng mã. Nhưng nó đã không bắt đầu theo cách đó. Ban đầu tôi đã sử dụng các khung kiểm thử đơn vị như một cách thuận tiện để viết các bài kiểm tra tích hợp.

Khái niệm thay đổi tên đã được đưa ra. Nó được gọi là Phát triển hướng hành vi . Những người đưa ra điều đó nhận thấy nhiều tranh luận tương tự cộng với sự phù hợp không tự nhiên để kiểm tra thứ gì đó chưa được tạo ra. Thay vào đó, khái niệm của họ là viết một đặc tả thực thi (đó là những gì TDD thực sự hướng tới).

Tôi đã nhận thấy sự đẩy lùi tương tự. Tôi cũng nhận thấy rằng một số người không biết cách viết bài kiểm tra đơn vị. Họ đang thiếu các quy trình khoa học và chỉ sử dụng khung kiểm tra đơn vị như một cách để kết nối mọi thứ lại với nhau và bắt đầu trình gỡ lỗi. Nói tóm lại, họ không thực sự cải thiện việc sử dụng thời gian của họ. Tôi không thể cho bạn biết có bao nhiêu bài kiểm tra đơn vị tôi đã thấy dài vài chục dòng (hơn 30 dòng) và không phải là một tuyên bố khẳng định. Khi tôi thấy điều đó, tôi biết rằng đã đến lúc làm việc với nhà phát triển và dạy cho họ biết khẳng định là gì và cách viết các bài kiểm tra đơn vị thực sự kiểm tra.

Hợp đồng được gọi là "giao diện" trong hầu hết các trường hợp ở đây. Có các bài kiểm tra đơn vị không đảm bảo các hợp đồng, vì bạn cũng có thể thay đổi các bài kiểm tra, vì vậy bạn thực sự không biết rằng bạn có thể sử dụng phiên bản mới của thư viện chỉ vì thư viện đã được kiểm tra. Bạn cũng cần kiểm tra mã sử dụng thư viện. Điều đó không khác với bất kỳ thử nghiệm đơn vị nào khác, vì vậy tôi không hiểu tại sao điều đó lại cần một tên mới.

Tôi nghĩ, giống như bạn, rằng hầu hết mọi người miễn cưỡng làm các bài kiểm tra làm như vậy bởi vì họ nghĩ rằng đó là công việc nhiều hơn và không sử dụng.

Tôi sẽ cho bạn biết lý do tại sao tôi không thích TDD: không phải vì tôi không thể thấy giá trị của nó hoặc nhận ra lợi ích của bộ kiểm tra mà tôi có thể chạy để xác minh tất cả mã của mình sau mỗi lần sửa đổi.

Đó là vì tôi không cần nó. Tôi là một học sinh khá lớn tuổi, khi tôi còn trẻ, chúng tôi không có trình gỡ lỗi tích hợp ưa thích nào với việc chỉnh sửa và tiếp tục viết mã, và một trình biên dịch có thể mất khá nhiều thời gian để chúng tôi phải lấy mọi thứ đúng, ngay từ đầu Được đào tạo như vậy, tôi thực sự không thấy rằng việc viết một loạt các bài kiểm tra đơn vị sẽ giúp tôi làm việc hiệu quả hơn hoặc mã của tôi không có lỗi hơn.

Tôi kiểm tra mã của mình, nhưng như tôi đã luôn làm, điều này là trên toàn bộ mọi thứ chứ không phải là từng phần riêng lẻ. Vì vậy, có lẽ tôi có 'bài kiểm tra đơn vị', nhưng chúng khá thô hơn.

Vì vậy, đó là lý do của tôi. Tôi không thể thấy sự cần thiết của tôi để làm điều đó. Mã tôi sản xuất là đủ tốt và nếu đó là lý do, tại sao tôi phải thay đổi các quy trình của mình để sửa lỗi không bị hỏng?