Phát triển theo hướng thử nghiệm với ASP.NET MVC - bắt đầu từ đâu?

Question

Tôi đã đọc rất nhiều về Phát triển theo hướng thử nghiệm (TDD) và tôi thấy các nguyên tắc rất hấp dẫn, dựa trên trải nghiệm cá nhân.

Hiện tại tôi đang phát triển một trang web cho một dự án khởi nghiệp mà tôi tham gia và tôi muốn thử dùng TDD để thực hành.

Vì vậy ... Tôi tạo một giải pháp trống trong Visual Studio 2010, thêm dự án ASP.NET MVC Website và dự án thử nghiệm.

Tôi cũng thêm thư viện lớp có tên 'Miền', cho đối tượng miền của tôi và dự án thử nghiệm cho điều đó.

Bây giờ tôi tự hỏi bắt đầu từ đâu. Tôi có nên viết một bài kiểm tra trước khi tôi làm bất cứ điều gì đúng không? Câu hỏi đặt ra là - tôi có nên bắt đầu viết các bài kiểm tra cho các đối tượng miền không? Nếu vậy, chính xác những gì tôi nên thử nghiệm, vì các đối tượng miền chưa tồn tại?

Hoặc tôi có nên bắt đầu với dự án Trang web và viết bài kiểm tra cho điều đó không? Nếu vậy, tôi nên viết bài kiểm tra để làm gì? Bộ điều khiển Home/Index hành động?

Answer 1

Tôi thường bắt đầu bằng cách thu thập một tập hợp các câu chuyện cho ứng dụng tôi sẽ phát triển. Từ đó tôi tạo ra một mô hình miền, thường là trên "giấy". Tôi sắp xếp các câu chuyện mà tôi sẽ triển khai và bắt đầu tạo mô hình miền trong DB cho tập hợp các câu chuyện đầu tiên.

Khi tôi có DB ban đầu, sau đó tôi sử dụng ORM, trong trường hợp của tôi, LINQ to SQL, để ánh xạ các bảng DB lên một nhóm các lớp ban đầu. Tôi thường không đơn vị thử nghiệm tạo ra mã vì vậy điều này mang lại cho tôi một số tiền hợp lý của mã như là một cơ sở để bắt đầu. Sau đó tôi tạo ra một phương thức sơ khai, mà ném một ngoại lệ không được thực hiện, để thực hiện một tính năng của lớp miền đầu tiên mà tôi đang làm việc. Thông thường, tôi bắt đầu với logic xác nhận. Một khi bạn có phương pháp stub của bạn, sau đó bạn có thể sử dụng menu chuột phải VS để tạo ra một hoặc nhiều bài kiểm tra đơn vị cho phương pháp đó. Sau đó, bạn đang trên con đường của bạn.

Khi tôi đã hoàn thành với các đối tượng miền cho câu chuyện đầu tiên, sau đó tôi bắt đầu làm việc với các khía cạnh MVC. Đầu tiên, tôi sẽ tạo các mô hình khung nhìn cho khung nhìn đầu tiên. Đây thường chỉ là một lớp container rỗng như là điểm này. Sau đó, tôi sẽ tạo chế độ xem và mạnh mẽ nhập vào chế độ xem. Tôi sẽ bắt đầu xác định chế độ xem, thêm thuộc tính vào mô hình xem khi cần theo chế độ xem. Lưu ý rằng vì mô hình khung nhìn chỉ đơn giản là một vùng chứa nên thường không có các xét nghiệm đơn vị liên kết với nó. Tuy nhiên nó sẽ được sử dụng trong các kiểm tra điều khiển tiếp theo. Khi xem xong (hoặc ít nhất là khái niệm ban đầu của tôi là hoàn thành), tôi sau đó tạo ra các hành động điều khiển gốc hoặc hành động cho nó, một lần nữa phương pháp sơ khai chỉ đơn giản là ném một ngoại lệ không được thực hiện. Quay lại đầu trang | Điều này là đủ để làm cho nó biên dịch và cho phép tôi sử dụng các công cụ để tạo các bài kiểm tra đơn vị cho nó. Tôi tiến hành khi cần thiết để kiểm tra (các) phương pháp và đảm bảo rằng nó hoạt động phù hợp với các đầu vào đã cho và tạo ra một mô hình xem thích hợp. Nếu phương thức có thể tạo nhiều mô hình xem, tức là, hiển thị nhiều chế độ xem tôi có thể lặp qua quy trình tạo mô hình xem/lượt xem/mã điều khiển cho đến khi câu chuyện hoặc câu chuyện hoàn tất.

Lặp lại khi cần thiết cho đến khi tập hợp các câu chuyện của bạn được triển khai, sắp xếp lại trên đường đi.

Answer 2

Bạn có thể nhìn vào ASP.NET MVC 1.0 Test Driven Development

Answer 3

kiểm tra đơn vị Viết trước khi thậm chí tuyên bố lớp bạn đang thử nghiệm dường như một chút cực đoan trong một ngôn ngữ tĩnh như C#. Vì vậy, bạn bắt đầu bằng cách khai báo các lớp miền của bạn, ném một vài giao diện xác định các hoạt động bạn sẽ thực hiện trên các đối tượng miền này và sau đó bạn thêm một lớp sẽ thực hiện một giao diện, để lại các phương thức chỉ cần ném NotImplementedException. Tại thời điểm đó bạn có thể viết một bài kiểm tra đơn vị cho lớp này, như tất cả các loại được biết đến. Bạn chạy thử nghiệm mà sẽ thất bại, sau đó bạn thực hiện các phương pháp và chạy thử nghiệm một lần nữa - nó sẽ vượt qua. Sau đó, bạn có thể refactor và tối ưu hóa việc thực hiện của bạn, kiểm tra đơn vị của bạn vẫn nên vượt qua.

Khi bạn có mô hình miền và lớp truy cập dữ liệu tốt, bạn có thể chuyển sang dự án web nơi bạn tạo bộ điều khiển, sử dụng giao diện bạn đã xác định trước đó (bằng cách tạo hàm tạo giao diện này). Bạn viết một bài kiểm tra đơn vị cho bộ điều khiển này bằng cách thay thế giao diện bằng một đối tượng giả, để bạn có thể kiểm tra các hành động của bộ điều khiển tách biệt khỏi mã truy cập dữ liệu của bạn.

Và quan trọng nhất: đừng ngại thêm lớp và giao diện. Tôi đã thấy mọi người viết những phương pháp khổng lồ thực hiện nhiều thứ cùng một lúc và rất khó để kiểm tra. Hãy thử cách ly các tác vụ khác nhau thành các phương thức mà bạn có thể dễ dàng viết các đặc tả cho: đầu ra nào bạn mong đợi cho các đầu vào có thể khác nhau.

Answer 4

Để có câu trả lời dài, bạn nên thực hiện các bước nhỏ như thế này.

1) -Trước hết viết một thử nghiệm thất bại

[Test] 
    public void AddSameTag() 
    { 
     UserMovie userMovie = new UserMovie(); 

     userMovie.AddTag("action", "dts", "dts"); 
     Assert.AreEqual(2, userMovie.Tags.Count); 
    } 

2) - Viết mã đơn giản nhất để vượt qua các bài kiểm tra.

public virtual void AddTag(params string[] tags) 
    { 
     foreach (var text in tags) 
     { 
      Tag tag =new Tag(text.Trim()); 
      if (!movieTags.Contains(tag)) 
       movieTags.Add(tag); 
     } 
    } 

3) - Refactor

. Đối với khởi động ASP.NET MVC và TDD, bạn có thể bỏ qua Kiểm tra điều khiển và tập trung vào Miền bằng TDD.