ASP.net MVC RTM Kiểm tra quy ước đặt tên

Question

Tôi đang làm việc trên một ứng dụng asp.net mvc và viết bài kiểm tra đơn vị BDD của tôi. Ví dụ:

GetResource_WhenResourceFileExists_ShouldReturnResources()

Nhưng khi tôi đang viết bài kiểm tra cho các bộ điều khiển của tôi, tôi thường có hai phương pháp có cùng tên. Một không có tham số để nhận yêu cầu và một cho bài đăng. Có ai có một quy ước đặt tên tốt ở đây để phân biệt giữa hai?

tôi có thể nghĩ:

1. 
LogIn_WithParameters_ShouldReturnLogInView() 
LogIn_WithoutParameters_WhenAuthenticationFailed_ShouldReturnLogInView() 
LogIn_WithoutParameters_WhenAuthenticationPassed_ShouldReturnProfileRedirect() 

2. 
LogIn_Get_ShouldReturnLogInView() 
LogIn_Post_WhenAuthenticationFailed_ShouldReturnLogInView() 
LogIn_Post_WhenAuthenticationPassed_ShouldReturnProfileRedirect() 

3. 
LogIn_ShouldReturnLogInView() 
LogIn_WhenCalledWithParametersAndAuthenticationFailed_ShouldReturnLogInView() 
LogIn_WhenCalledWithParametersAndAuthenticationPassed_ShouldReturnProfileRedirect() 

ý kiến ​​Bất kỳ?

Answer 1

Tôi nghĩ đây là một ví dụ hoàn hảo về lý do tại sao các quy ước đặt tên cứng nhắc cho các bài kiểm tra đơn vị là không hấp dẫn.

Đề xuất được đề xuất của bạn sẽ chỉ hoạt động khi bạn có hai quá tải phương thức: một và không có thông số. Nó không mở rộng đến kịch bản mà bạn có nhiều hơn một quá tải với các thông số khác nhau.

Cá nhân tôi muốn có một quy ước đặt tên lỏng hơn nhiều mà có thể được tóm tắt như

[Action][Will|Should|Is|...][Result] 

này mang lại cho tôi sự linh hoạt để đặt tên cho các bài kiểm tra của tôi

SutIsPathResolutionCommand 
ExecuteWithNullEvaluationContextWillThrow 
ExecuteWillAddDefaultClaimsTransformationServiceWhenNoConnectionServiceIsAvailable 

Tôi phải thừa nhận rằng tôi hiếm khi đọc tên của kiểm tra anyway. Thay vào đó, tôi đọc đặc tả của nó (tức là mã thử nghiệm). Cái tên đó không quan trọng với tôi.

Answer 2

tôi sử dụng định dạng sau đó hoạt động rất tốt đối với tôi:

[TestFixture]  
public class Log_in_with_parameters_should 
{ 
    [Test] 
    public void Return_the_log_in_view() {} 
} 

[TestFixture]  
public class Log_in_without_parameters_should 
{ 
    [Test] 
    public void Return_the_log_in_view_when_the_authentication_failed() {} 

    [Test] 
    public void Redirect_to_the_profile_when_the_authentication_passed() {} 
} 

Answer 3

Một lựa chọn, mà tôi không đặc biệt như thế, là để cung cấp cho các hoạt động điều khiển tên gọi khác nhau, nhưng để sau đó đổi tên họ bằng cách sử dụng Thuộc tính ActionName:

public ActionResult Login() { 
    // ... code ... 
    return View(); 
} 

[HttpPost] 
[ActionName("Login")] 
public ActionResult LoginPost(... some params ...) { 
    // ... more code ... 
    return View(); 
} 

Điều này về cơ bản thay thế một vấn đề (đặt tên kiểm tra đơn vị) với một vấn đề khác (khó đọc mã bộ điều khiển). Tuy nhiên, bạn có thể thấy mẫu này hấp dẫn vì nó giải quyết được vấn đề đã nêu.

Answer 4

Tôi có thể không trả lời câu hỏi của bạn, nhưng tôi muốn chia sẻ những gì tôi làm. Tôi không tuân theo quy ước đặt tên cụ thể, nhưng tôi cố gắng cung cấp cho các tên giải thích phương pháp thử nào đang thử nghiệm. Một số trường hợp mà tôi cần giải thích thêm tôi thêm mô tả [Test ("Bài kiểm tra này đánh giá có bao nhiêu câu hỏi được trả lời bởi người dùng cụ thể")].

Một điều cần đảm bảo là các bài kiểm tra dễ đọc và dễ hiểu hơn.

Answer 5

tôi sử dụng một quy ước đặt tên tương tự như một trong câu hỏi của bạn tức là method_scenario_expected Tôi nghĩ bạn nên xây dựng thêm về phần "kịch bản" - nếu bạn đang đi qua các thông số - để cho người đọc biết những gì là speacial về họ .

Hãy nhớ rằng việc đặt tên cho các thử nghiệm của bạn theo cách này là "TDD đã được khai thác" và không có tên kiểm tra BDD - BDD nào về quy tắc và "hành vi :.

Nếu bạn cảm thấy rằng quy ước đặt tên hiện tại không hwlp khả năng đọc mã - hãy thử nghiệm xung quanh và tìm những gì phù hợp với bạn.