Bạn nghĩ gì về "Kiểm tra, Kiểm tra, Thử nghiệm" có mặt khắp nơi! nguyên tắc?

Question

Trong những ngày cũ, chương trình được sử dụng để tham gia ít phỏng đoán hơn. Tôi sẽ viết một số dòng mã và chắc chắn 100% về mã nguồn và những gì nó không có trong nháy mắt. Lỗi chủ yếu là lỗi chính tả, nhưng không phải về chức năng.

Những năm gần đây tôi tin rằng có một xu hướng cho chương trình "thử và lỗi" này: viết mã (như dự thảo) và sau đó gỡ lỗi lặp lại cho đến khi hành vi của chương trình có vẻ tuân thủ các yêu cầu. Kiểm tra, và kiểm tra lại, và sau đó một lần nữa. Điều thú vị là, trong Visual Studio của tôi nút "Chạy" đã được thay thế bằng một nút có nhãn "Gỡ lỗi" (= Tôi biết bạn có một số lỗi!). Tôi phải thừa nhận rằng trong một số ứng dụng mà tôi viết, tôi không thể đảm bảo mã không có lỗi.

Bạn nghĩ sao? Hoặc có thể hệ thống của chúng tôi hiện đang quá phức tạp (tương thích với trình duyệt/OS/Service Pack, v.v.) và điều này biện minh cho tất cả các loại môi trường.

Answer 1

Câu trả lời một từ là "Phức tạp". Câu trả lời thực sự là "Phức tạp không cần thiết"! Các nguyên tắc kế toán đã không thay đổi trong 30 năm qua. Tại sao sau đó viết một hệ thống kế toán ngày nay khó khăn hơn nhiều? Nó là tốt để có một giao diện người dùng đồ họa nhưng chúng ta phải đi overboard?

Phát triển phần mềm đã bị bắt trong một vòng luẩn quẩn trong nhiều năm. Sự phức tạp là ăn chính nó và thay vì giảm nó, chúng tôi chỉ đơn giản là ẩn nó dưới lớp và lớp bao bọc. Cuối cùng một cái gì đó sẽ cung cấp cho.

Khi chúng tôi ưu tiên hình thức vượt chức năng, chúng tôi phải trả giá.

Answer 2

Tôi đã trải nghiệm điều ngược lại. Trong khi nó từng là một trường hợp chạy cho đến khi nó hoạt động, bây giờ tôi kiểm tra đơn vị cho đến khi các bài kiểm tra vượt qua ... và điều này có vẻ ít nhất là hợp lý chuyển đổi chung, theo như tôi thấy.

Tôi phải nói rằng mã hoạt động lần đầu với chỉ lỗi chính tả có không bao giờ là tiêu chuẩn trong kinh nghiệm của tôi. Sự khác biệt là bây giờ tôi có thể tìm thấy các vấn đề nhanh hơn nhiều, và cũng phát hiện ra nếu các vấn đề cũ trở lại. Đôi khi tôi có thể quản lý các đoạn mã khá ngắn và đơn giản mà không có lỗi (và đăng trên Stack Overflow đã cải thiện khả năng đó) nhưng các hệ thống phức tạp, lớn? Quái gì không.

Để trả lời tiêu đề bài đăng của bạn - nguyên tắc "kiểm tra, kiểm tra, kiểm tra" là một nguyên tắc tốt, theo quan điểm của tôi ... nhưng tôi không liên kết với việc chạy toàn bộ chương trình nhiều lần. Tôi liên kết nó với các bài kiểm tra đơn vị chạy thường xuyên. Tôi hiếm khi cần phải sử dụng trình gỡ lỗi cho các bài kiểm tra đơn vị - thường là một sự thất bại làm cho nguyên nhân phù hợp rõ ràng bằng cách kiểm tra, bởi vì chỉ một lượng nhỏ mã đang được thử nghiệm.

Answer 3

Có thể nào trong những năm sau các nhà phát triển đã nhận ra rằng "chắc chắn 100%" có thể không thực sự chính xác? Phát triển phần mềm là rất phức tạp, và mặc dù các công cụ đã phát triển qua nhiều năm, do đó, chúng tôi nhận ra rằng viết mã tốt là khó. Các thử nghiệm đơn vị đúng, gỡ lỗi và tự động đã làm cho chúng ta hiệu quả hơn, nhưng chúng ta vẫn tạo ra lỗi, giống như chúng ta đã làm lúc trước, chỉ bây giờ chúng ta có các công cụ khác nhau để bắt chúng.

Answer 4

Bạn có thể viết mã mà bạn nghĩ rằng bạn biết 100% những gì nó làm và không làm, nhưng luôn luôn có trường hợp cạnh mà bạn không nghĩ đến hoặc ngoại lệ lẻ ném mà bạn không mong đợi. Một số lần lập trình thử và lỗi có thể là một công cụ hữu ích để thu hẹp sự cố, với sự trợ giúp của trình gỡ rối.

Điều quan trọng là phải biết những công cụ nào có sẵn cho bạn để giúp tạo mã bằng các lỗi nhỏ nhất.

Answer 5

Tôi nhận thấy rằng phương pháp Kiểm tra thử nghiệm giúp tôi thiết kế mã. Đôi khi công việc phải được thực hiện quá phức tạp để làm tất cả trong một. Thử nghiệm buộc tôi chia nó thành những phần nhỏ hơn và khi tôi giải quyết những điều này, tôi có thể đặt chúng lại với nhau thành một tổng thể lớn hơn.

Answer 6

Tôi nghĩ lợi thế do thỏa thuận hợp một cách gián tiếp: Khi bạn ôm kiểm tra và kiểm tra đơn vị, bạn phải viết ứng dụng của bạn trong một cách mà bạn thực sự có thể viết bài kiểm tra:

• Lớp học cần phải được được viết theo cách mà bạn có thể khởi tạo một đối tượng đơn lẻ mà không có toàn bộ ứng dụng và hệ điều hành xung quanh nó, nhưng chỉ là một vài đối tượng trợ giúp. Điều này có nghĩa là bạn cần phải giảm thiểu các phụ thuộc, và làm cho tất cả các giao tiếp với hệ thống xung quanh rõ ràng.

• Thực hiện các trường hợp kiểm tra có nghĩa là bạn phải tìm một chuỗi lệnh và cuộc gọi tối thiểu làm cho lớp của bạn làm điều gì đó có ý nghĩa. Điều này thường chỉ ra các quyết định thiết kế khó xử, hoặc cho bạn thấy rằng các lớp học rất khó sử dụng cho các mục đích nhất định.

Tất cả trong tất cả, khi bạn kiểm tra, bạn kết thúc với một hệ thống có tối thiểu phụ thuộc lẫn nhau giữa các thành phần và trường hợp thử nghiệm.

Answer 7

Kiểm tra (thực thi hệ thống) cho bạn biết điều gì đó về "sự hiện diện của các lỗi nhưng KHÔNG về sự vắng mặt của chúng" (afaik thuật ngữ này được cojed bởi dijkstra). Nó chỉ hướng mà sức mạnh của bộ kiểm thử của bạn là chìa khóa của thử nghiệm: "Bạn có rất nhiều trường hợp kiểm tra, bạn có thể nói, rằng nhiều lỗi không tồn tại. Điều này ngụ ý rằng phần lớn phần mềm của bạn hoạt động như mong đợi ".

Một số ví dụ cho việc có một/hùng mạnh kiểm tra-suite mạnh:

• Rất nhiều mã được thực thi bởi các xét nghiệm đơn vị của bạn (thuật ngữ bảo hiểm truyền thống)
• Bạn không có xét nghiệm âm tính giả (thử nghiệm hiển thị màu xanh lá cây nhưng trên thực tế phải có màu đỏ). Thử nghiệm âm tính giả là điều xấu, bởi vì chúng cho bạn cảm giác sai về chất lượng trường hợp thử nghiệm. Để biết chi tiết về xác nhận thử nghiệm tốt và phủ định sai, hãy xem thêm blog-entry#1 và blog-entry#2.
• Các yêu cầu được hiểu rõ (Tôi đã thấy nhiều trường hợp thử nghiệm tự động đã kiểm tra sai và nhà phát triển hiểu sai yêu cầu từ doanh nghiệp). Đối với nhà phát triển là màu xanh lá cây, nhưng đối với doanh nghiệp, hệ thống không hoạt động như mong đợi (một loại ví dụ phủ định sai khác nhưng ở mức cao hơn).

Trong ý nghĩa, tính chính xác của chương trình chỉ được chứng minh, khi nó được thực hiện bằng chứng toán học (chỉ trả tiền cho các hệ thống quan trọng và tiền bạc). Tuy nhiên, bạn có thể đạt được rất nhiều thử nghiệm tự động (ngoài việc thử nghiệm đơn vị, thử nghiệm tích hợp tự động luôn giúp ích rất nhiều).

Về gỡ rối: Tôi sử dụng gỡ lỗi thường xuyên như trước đây, nhưng đôi khi khi thêm chức năng mới để mã (trường hợp thử nghiệm mới của tôi hiển thị màu xanh lá cây) tôi phá vỡ các trường hợp thử nghiệm khác. Bởi khẳng định tôi ngay lập tức thấy rằng có điều gì đó sai, nhưng vẫn không xác định được lỗi. Để xác định lỗi gỡ lỗi vẫn hữu ích (với trường hợp thử nghiệm màu đỏ, tôi thực thi các đường dẫn mã có vấn đề, với trình gỡ rối tôi định vị lỗi này).

Nếu bạn quan tâm đến kiểm tra tự động hóa, hãy xem kiệt tác xUnit Test patterns.

Answer 8

Tôi hiện đang thực hành Kiểm tra phát triển theo hướng (TDD) hoặc ít nhất viết nhiều bài kiểm tra đơn vị để xác minh rằng hầu hết/tất cả mã của tôi đều hoạt động theo cách tôi mong đợi. Sử dụng cách tiếp cận này buộc tôi phải xem xét chương trình của mình từ quan điểm của người tiêu dùng. Ngoài ra, khi tôi viết các bài kiểm tra, tôi thường nghĩ về giới hạn ranh giới, các tình huống bổ sung mà tôi không hình dung ban đầu, v.v.

Tôi đã đến lúc tôi sợ thay đổi các chương trình cũ hơn, vì tôi sợ rằng tôi sẽ phá vỡ một cái gì đó. Kiểm tra hồi quy là hợp lý, so với việc chạy một bộ kiểm thử đơn vị.

Answer 9

Tôi đã đọc một cuốn sách ("TDD by example" của Kent Beck) thực sự có vẻ là một cách tiếp cận "thử và lỗi" cực đoan: nhưng nó giống như "làm cho bài kiểm tra đơn vị hoạt động". Tuy nhiên, tôi không thể hoàn thành cuốn sách này - một sự xuất hiện hiếm hoi, đặc biệt là vì tôi thực sự hy vọng sẽ hiểu rõ hơn. Tuy nhiên, cam kết rõ ràng mã imbecile được cải thiện sau này làm cho tôi rùng mình.

Khoa học: Kiểm tra tự động có lợi thế của chúng. Tuy nhiên, chúng không phải là viên đạn bạc mà chúng được yêu cầu. Không có phương pháp thử nghiệm nào là đủ để tìm ra lỗi, và các phương pháp khác có tỷ lệ phát hiện tốt hơn.

Cảm nhận: Vấn đề của chúng tôi là các khía cạnh phức tạp ngày càng tăng. Độ phức tạp cao tương quan với lượng mã chúng ta phải quản lý. Trong ánh sáng này, TDD cố gắng giải quyết các sự cố của tới nhiều mã bằng cách viết nhiều mã hơn.

Ưu điểm: Hiện tại chúng tôi có một hình thức đã được thiết lập để kiểm tra có thể lặp lại, có trách nhiệm và được lập tài liệu ngay lập tức. Nó chắc chắn là một cách ra khỏi "công trình trên máy tính của tôi" và "kỳ lạ, nó đã làm việc ngày hôm qua, tôi sẽ cung cấp cho bạn những" DLL mới nhất "bẫy.