Nhập liệu ngầm và TDD

Question

Tôi chỉ đọc post và nó làm cho trường hợp chống lại việc gõ ngầm khi sử dụng khi bắt đầu với thiết kế/phát triển theo hướng thử nghiệm.

Bài đăng của anh ấy nói rằng TDD có thể bị "chậm lại" khi sử dụng nhập ẩn cho loại trả về khi đơn vị kiểm tra phương thức. Ngoài ra, anh ta dường như muốn loại trả về được chỉ định bởi thử nghiệm để thúc đẩy phát triển (điều này có ý nghĩa với tôi).

Một thử nghiệm đơn vị đưa ra với gõ ngầm có thể trông như thế này:

public void Test_SomeMethod() 
{ 
    MyClass myClass = new MyClass(); 

    var result = myClass.MethodUnderTest(); 
    Assert.AreEqual(someCondition, result); 
} 

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

Không sử dụng ngầm giúp đỡ đánh máy hoặc cản trở các bài kiểm tra viết đơn vị cho TDD? Có ai ngoài kia có thể chia sẻ kinh nghiệm của họ bằng cách sử dụng kỹ thuật này khi viết các bài kiểm tra đơn vị không?

Tôi hỏi điều này vì chẳng bao lâu tôi chưa thực hiện TDD và muốn biết nếu có cách viết các bài kiểm tra đơn vị chung hoặc bán chung sẽ làm việc kiểu trả về có thể thay đổi.

Answer 1

Tôi thấy quan điểm của mình nhưng tôi không thực sự nghĩ đó là lý do chính đáng để không sử dụng var tại đây. Hãy nhớ rằng, TDD hoạt động gần như sau:

1. Viết một thử nghiệm mới.
2. Nếu thử nghiệm không biên dịch được (và nó sẽ thất bại!), Hãy viết đủ mã cho đến khi biên dịch thử nghiệm.
3. Chạy tất cả các thử nghiệm.
4. Nếu thử nghiệm không thành công, hãy viết đủ mã cho đến khi tất cả các thử nghiệm vượt qua.
5. Refactor.

Có hay không chúng tôi sử dụng var thử nghiệm sẽ không biên dịch theo cách vì phương pháp được thử nghiệm sẽ không tồn tại! Khi chúng tôi bắt đầu mã hóa NewMethod, điểm của anh ấy là khá thú vị.

Đúng hơn, lý do chính đáng để không sử dụng var ở đây là do mã không cho biết loại result là gì. Đây là một vấn đề quan điểm nhưng var là okay đây

var dict = new Dictionary<Foo, List<Bar>>(); 

và với nhiều loại vô danh nhưng không ở đây

var m = M(); 

vì nó hoàn toàn không rõ ràng mà không đi đến tuyên bố M (hoặc sử dụng IntelliSense) những gì kiểu trả về là M.

Answer 2

Có và Không

Trong Visual Studio hiện nay, TDD là một chút đau đớn, đặc biệt là khi sử dụng implicity gõ. var có nghĩa là không có intellisense, sau đó khi bạn nhập tên của một loại có thể không tồn tại nhưng nó có xu hướng tự động hoàn thành với một cái gì đó là tương tự với những gì bạn đang gõ, thường là tên của vật cố thử nghiệm.

Visual Studio 2010 có consume first mode, điều này làm cho nó trở nên lý tưởng và tốt hơn cho Phát triển theo hướng thử nghiệm.Hiện tại bạn sẽ tìm thấy (trong năm 2008 và trước đó) bạn phải nhấn thoát để ẩn nội dung.

Đối với sử dụng var đó là đường hoàn toàn synatic. Nó làm cho điều sau đây đẹp hơn nhiều theo ý kiến ​​của tôi:

var type = new MyType(); 

Rõ ràng là loại biến, thuộc loại MyType. var là rất tốt cho Generics và theo prinicple của DRY - Do not Repeat Yourself.

var type = MethodCall(); 

var result = ReturnResult(); 

Mặt khác, điều này làm cho mã khó đọc, dù bạn có theo TDD hay không. Các bài kiểm tra đơn vị tốt nên lưu thông và dễ đọc. Nếu bạn phải suy nghĩ, hoặc di chuột qua một phương thức để xem kiểu trả về, đó là dấu hiệu của một bài kiểm tra xấu, khó đọc.

Answer 3

Từ góc độ dụng cụ, tôi muốn nói rằng nó đẹp hơn để tránh những var. Tôi sử dụng Eclipse và Java, nhưng tôi biết rằng các phần mở rộng như CodeRush và Resharper cung cấp nhiều tính năng mà tôi đang thảo luận ở đây. Khi trong bài kiểm tra của tôi, tôi gọi một phương thức chưa tồn tại, tôi có thể "sửa nhanh" nó để tạo phương thức trong lớp mong muốn. Kiểu trả về của phương thức được tạo tự động phụ thuộc vào ngữ cảnh của nó; nếu tôi đang mong đợi trở lại một String, kiểu trả về của phương thức sẽ là String. Nhưng nếu gán là một var (mà Java không có - nhưng nếu nó đã làm), IDE sẽ không biết đủ để làm cho kiểu trả về bất cứ điều gì khác hơn là var (hoặc có thể là Object).

Không phải ai cũng sử dụng các IDE theo cách này trong TDD, nhưng tôi thấy nó rất hữu ích. Càng có nhiều thông tin tôi có thể cung cấp cho IDE trong bài kiểm tra của tôi, tôi càng phải gõ ít để thực hiện bài kiểm tra.