Chúng ta có cần Đăng nhập khi làm TDD không?

Khi thực hiện chu trình Đỏ, Xanh & Tái cấu trúc, chúng ta phải luôn viết mã tối thiểu để vượt qua bài kiểm tra. Đây là cách tôi đã được dạy về TDD và cách mà hầu hết các cuốn sách mô tả quá trình.

Nhưng những gì về đăng nhập?

Thành thật mà nói tôi hiếm khi sử dụng đăng nhập vào một ứng dụng trừ khi có điều gì đó thực sự phức tạp đang xảy ra, tuy nhiên, tôi đã thấy nhiều bài viết nói về tầm quan trọng của việc đăng nhập đúng cách.
Vì vậy, ngoài việc đăng nhập một ngoại lệ, tôi không thể chứng minh tầm quan trọng thực sự của việc đăng nhập vào một ứng dụng được kiểm tra thích hợp (kiểm tra đơn vị / tích hợp / chấp nhận).

Vì vậy, câu hỏi của tôi là:

1. Chúng tôi có cần đăng nhập nếu chúng tôi đang làm TDD không? một bài kiểm tra thất bại sẽ tiết lộ điều gì sai với ứng dụng?
2. Chúng ta có nên thêm kiểm tra cho quá trình đăng nhập trong mỗi phương thức trong mỗi lớp không?
3. Ví dụ, nếu một số cấp độ nhật ký bị vô hiệu hóa trong môi trường sản xuất, liệu điều đó có gây ra sự phụ thuộc giữa các thử nghiệm và môi trường không?
4. Mọi người nói về cách các bản ghi dễ dàng gỡ lỗi, nhưng một trong những lợi thế chính của TDD là tôi luôn biết những gì sai do thử nghiệm thất bại.

Có cái gì tôi đang bỏ lỡ ngoài kia?

1) Chúng ta có cần đăng nhập nếu chúng ta đang làm TDD không? một bài kiểm tra thất bại sẽ tiết lộ điều gì sai với ứng dụng?

Điều đó giả định rằng bạn có mọi thử nghiệm có thể có về nhu cầu ứng dụng của bạn, điều này hiếm khi đúng. Nhật ký giúp bạn theo dõi các lỗi mà bạn chưa viết bài kiểm tra.

2) Chúng ta có nên thêm kiểm tra cho quá trình đăng nhập trong mỗi phương thức trong mỗi lớp không?

Nếu bản thân logger được kiểm tra, nó sẽ không cần phải kiểm tra lại trong mỗi lớp, tương tự như các phụ thuộc khác.

3) Nếu một số cấp độ nhật ký bị vô hiệu hóa trong môi trường sản xuất chẳng hạn, liệu điều đó có gây ra sự phụ thuộc giữa các thử nghiệm và môi trường không?

Con người (và tập hợp nhật ký) phụ thuộc vào nhật ký, các bài kiểm tra không nên phụ thuộc vào chúng. Thông thường có một số cấp độ nhật ký và một số cấp độ được sử dụng trong sản xuất và một số cấp độ bổ sung được sử dụng trong phát triển, tương tự như:

"Cấp độ nhật ký Rails là thông tin trong chế độ sản xuất và gỡ lỗi trong quá trình phát triển và thử nghiệm" - http://guides.rubyonrails.org/debugging_rails_appluggest.html

Các ứng dụng khác sử dụng một cách tiếp cận tương tự.

4) Mọi người nói về cách các bản ghi dễ dàng gỡ lỗi, nhưng một trong những lợi thế chính của TDD là tôi luôn biết những gì sai do thử nghiệm thất bại.

Lỗi sản xuất sẽ vượt qua tất cả các bài kiểm tra, vì vậy bạn có thể cần một số tài liệu tham khảo khác để điều tra những vấn đề đó.

Ghi nhật ký rất hữu ích để giải thích hành vi không đặc biệt của ứng dụng:

Nhật ký sự kiện ghi lại các sự kiện diễn ra trong quá trình thực thi một hệ thống nhằm cung cấp một bản kiểm toán có thể được sử dụng để hiểu hoạt động của hệ thống và chẩn đoán các vấn đề. Chúng rất cần thiết để hiểu hoạt động của các hệ thống phức tạp, đặc biệt trong trường hợp các ứng dụng có ít tương tác người dùng (như ứng dụng máy chủ ) ...

Bất kể ứng dụng đã được thử nghiệm như thế nào và cho dù các trường hợp ngoại lệ được ghi lại tốt như thế nào, người dùng ứng dụng có thể hỏi,

đầu ra của chương trình của bạn là 0 trong khi chúng tôi dự kiến ​​là 1, tại sao vậy?

Bạn cần đăng nhập để xác minh cấu hình ứng dụng, tham số và các chi tiết thời gian chạy khác để giải thích hành vi (không đặc biệt) của nó.

Từ quan điểm trên, đăng nhập là định hướng hỗ trợ nhiều hơn là phát triển. Sau khi ứng dụng đi vào hoạt động, mong muốn để người khác xử lý các câu hỏi từ người dùng, để cho phép các lập trình viên tập trung vào phát triển hơn nữa.

Ghi nhật ký ứng dụng nào cho phép người khác hiểu hành vi của chương trình mà không cần đào sâu vào mã và không làm phân tâm các nhà phát triển bằng các yêu cầu giải thích những gì đang diễn ra.

Hầu hết các câu trả lời ở đây tập trung vào khía cạnh của sự chính xác. Nhưng việc ghi nhật ký cũng phục vụ một mục đích khác: Ghi nhật ký có thể là một cách để thu thập dữ liệu liên quan đến hiệu suất. Vì vậy, ngay cả khi hệ thống hoạt động mà không có lỗi, một bản ghi có thể cho biết tại sao nó chậm. Ngay cả với phạm vi kiểm tra đầy đủ về tất cả các khía cạnh, một bộ kiểm tra sẽ không nói.

Tất nhiên một hệ thống quan trọng về hiệu suất có thể / nên cung cấp các số liệu hiệu suất chính cho một số bảng điều khiển hoạt động, nhưng ghi nhật ký "cổ điển" có thể cung cấp một mức độ chi tiết khác.

Câu trả lời ngắn cho câu hỏi chính của bạn là: như một quy tắc chung, các lỗi trong mã của bạn sẽ KHÔNG bị TDD phơi bày. Một số có thể, lý tưởng là nhiều, nhưng sự vắng mặt của các bài kiểm tra thất bại không có nghĩa là không có lỗi. Đây là một câu châm ngôn rất quan trọng trong kiểm thử phần mềm.

Vì bạn không thể biết liệu bạn sẽ có hành vi không chính xác trong hệ thống của mình hay không, có thể trong các điều kiện hiếm gặp, đăng nhập là một công cụ hữu ích có thể giúp hiểu những gì sai khi mọi thứ chắc chắn xảy ra sai.

Ghi nhật ký và TDD giải quyết các mối quan tâm khác nhau.

1. Trừ khi bạn có vỏ bọc kiểm tra 100%, thường là không phải vậy, bạn không thể biết rằng phần mềm của bạn sẽ không bao giờ bị sập (EDIT: và - như đã nói trong các nhận xét - ngay cả khi có, một cái gì đó độc lập với phần mềm của bạn có thể gây ra một vụ tai nạn); nó giống như bạn nghĩ rằng bạn có thể làm một phần mềm hoàn toàn không có lỗi (thậm chí NASA không thể làm điều này). Vì vậy, ít nhất, bạn cần phải ghi lại những thất bại có thể xảy ra trong trường hợp chương trình của bạn gặp sự cố để bạn có thể biết tại sao.

2. Việc ghi nhật ký phải được thực hiện bởi một thư viện bên ngoài hoặc khung thực tập tùy thuộc vào công nghệ bạn đang sử dụng. Điều tôi muốn nói là nó phải là thứ gì đó đã được thử nghiệm trước đó và bạn không cần phải tự kiểm tra. Thật quá đáng khi kiểm tra rằng mọi phương pháp đều ghi lại những thứ mà nó được cho là.

3. Các nhật ký không có nghĩa là để kiểm tra, không nên phụ thuộc bất cứ điều gì. Điều đó nói rằng, bạn không cần phải vô hiệu hóa đăng nhập để kiểm tra nếu cảm thấy đó là một ràng buộc đối với bạn, mặc dù các nhật ký nên được giữ trong một tệp tương ứng với môi trường (bạn nên có một tệp khác cho môi trường thử nghiệm, phát triển và sản xuất ít nhất).

4. Một lỗi có thể rất không rõ ràng và không phải lúc nào cũng có lỗi rõ ràng khi một bài kiểm tra TDD thất bại. Nhật ký nên chính xác hơn. Chẳng hạn, nếu bạn đang thực hiện một thuật toán sắp xếp và toàn bộ trường hợp thử nghiệm thất bại, bạn nên có nhật ký cho mỗi lần kiểm tra thuật toán giúp bạn phát hiện ra vấn đề thực sự nằm ở đâu.

Có, trong trường hợp chung bạn cần đăng nhập.

Ghi nhật ký không phải là về gỡ lỗi. Chà, OK, một phần của việc đăng nhập đôi khi là về gỡ lỗi và bạn có thể bỏ qua phần đó nếu bạn không cần nó trong quá trình phát triển.

Nhưng phần quan trọng hơn của việc đăng nhập là về khả năng bảo trì. Ghi nhật ký được thiết kế tốt có thể trả lời các câu hỏi sau:

• Là ứng dụng vẫn còn sống và đá? (Bằng cách đăng nhập một nhịp tim cứ sau 1000 giây.)
• Hiệu suất của ứng dụng có thay đổi trong 10 tháng qua không? (Bằng cách ghi lại số liệu thống kê về hiệu suất của các trường hợp sử dụng.)
• Có phải tải trọng của sự thay đổi trong 10 tháng qua không? (Bằng cách đăng nhập số lượng yêu cầu cho mỗi loại yêu cầu.)
• Có bất kỳ giao diện của chúng tôi thay đổi đặc điểm hiệu suất của họ?
• Có phải bản phát hành mới gây ra một đặc tính sử dụng khác nhau đối với một số hệ thống con?
• Có phải chúng ta đang bị tấn công DoS ?
• Những loại lỗi đang xảy ra?

Tất cả điều này có thể đạt được bằng cách đăng nhập. Và có, nó nên được lên kế hoạch và thiết kế và thử nghiệm, tốt nhất là tự động.

Ghi nhật ký là một tính năng giải quyết điều trị, giống như các tính năng khác.

TL; DR: Ghi nhật ký và TDD là trực giao. Có một người không có nhu cầu cần người khác

Chúng tôi có cần đăng nhập nếu chúng tôi đang làm TDD không? một bài kiểm tra thất bại sẽ tiết lộ điều gì sai với ứng dụng?

Bởi hầu hết các bản ghi nhật ký mà tôi đã triển khai và tôi đã thấy đã triển khai là để khắc phục sự cố hoạt động, không phải để gỡ lỗi phát triển (mặc dù điều này có thể giúp ích). Đối tượng chính cho việc ghi nhật ký này là quản trị viên và các nhân viên điều hành máy chủ của bạn, hỗ trợ những người có nhật ký gửi cho họ để phân tích và khách hàng muốn xem nhật ký và thử tìm hiểu xem chuyện gì đang xảy ra.

Các nhật ký này có mặt để giúp khắc phục sự cố phần lớn làm cho các điểm tích hợp. Điều này có thể dịch vụ mạng (cơ sở dữ liệu, xà phòng, v.v.), tài nguyên cục bộ (đĩa, bộ nhớ, v.v.), dữ liệu xấu (đầu vào của khách hàng, nguồn dữ liệu xấu / hỏng, v.v.), v.v. (cài đặt, cấu hình, v.v.) đều có thể giúp khắc phục sự cố.

Chúng ta có nên thêm kiểm tra cho quá trình đăng nhập trong mỗi phương thức trong mỗi lớp không?

Thêm thử nghiệm bất cứ nơi nào bạn cần để kiểm tra đăng nhập. Nếu bạn có các cuộc gọi ad hoc để đăng xuất thông tin thì chúng nên được kiểm tra. Mặc dù nếu bạn triển khai kiểm tra ghi nhật ký và ghi nhật ký bằng cách sử dụng Lập trình theo định hướng hoặc lập trình meta, điều đó có thể làm giảm gánh nặng của kiểm tra.

Ví dụ, nếu một số cấp độ nhật ký bị vô hiệu hóa trong môi trường sản xuất, liệu điều đó có gây ra sự phụ thuộc giữa các thử nghiệm và môi trường không?

Nếu bạn đang viết mã bằng IoC và bạn sử dụng các giả, bạn sẽ có thể kiểm tra hiệu quả tất cả việc ghi nhật ký của mình mà không cần dựa vào một thiết lập môi trường cụ thể.

TDD thường giúp giảm lỗi mã hóa. Nó giúp ít hơn rất nhiều với các lỗi với đặc điểm kỹ thuật hoặc chỉ hiểu sai về cách mọi thứ hoạt động.

"Ồ? Bạn có thể nhận được một tin nhắn dữ liệu trước khi bạn xác nhận đăng nhập thành công? Tôi không bao giờ biết điều đó, nó sẽ không xử lý được điều đó!" ... Kiểu đó. Ghi nhật ký rất hữu ích để cho bạn biết phần mềm đã cố gắng làm gì để bạn có thể phát hiện ra điều bạn đã làm sai.

Theo kinh nghiệm của tôi, mức độ ghi nhật ký tuyệt vời được thêm vào ứng dụng khi chúng tôi không làm TDD. Sau đó, mức độ không chắc chắn trở nên cao do đó chúng tôi thêm ghi nhật ký để xem những gì đang xảy ra.

Trong khi đó khi thực hiện TDD (hoặc có thể kiểm tra - bất cứ khi nào) tôi thấy mình thêm các báo cáo nhật ký ít hơn rất nhiều. Điều này có nghĩa là ít LỘC và có thể (không phải luôn luôn) ảnh hưởng đến hiệu suất.

Nhưng chúng tôi thêm nhật ký xuất nhập cho các chức năng theo cách bán tự động tại công ty của tôi trong hầu hết các trường hợp bất kể phương thức phát triển. Theo tôi biết điều này được coi là bắt buộc để phân tích vấn đề sản xuất.

Ví dụ có thể là các phương thức của bean dịch vụ EJB có trên giao diện công cộng. Một trường hợp khác có thể là một trường hợp khi một hàm thực hiện các phép tính phức tạp. Nó có thể giúp rất nhiều để có các số liệu nhập vào phương thức (ví dụ: bạn có thể viết một bài kiểm tra đơn vị để quay lại chủ đề chung trong tay).