Bắt đầu dự án mới với TDD

Tôi đang học TDD và tôi đọc rằng nó cũng giúp bạn xác định thiết kế của ứng dụng, đúng không?

Vì vậy, tôi quyết định bắt đầu tạo một dự án mới để giúp tôi hiểu rõ hơn về nó.

Tôi muốn tạo một hệ thống đăng ký người dùng đơn giản sẽ hỏi tên, địa chỉ email, quốc gia (sẽ chọn một từ danh sách) và số điện thoại.

Vì vậy, câu hỏi là ...

Tôi đã tạo một giải pháp mới trong VS 2010, thêm một dự án Thử nghiệm mới và tôi chỉ không biết nên viết thử nghiệm nào!

Vì nó sẽ giúp tôi xác định thiết kế, tôi có thể viết bài kiểm tra nào ở đây?

Cảm ơn vì bất kì sự giúp đỡ!

Khi bạn viết bài kiểm tra đơn vị, bạn đang kiểm tra hành vi của ứng dụng của mình, vì vậy câu hỏi quan trọng cần đặt ra là ứng dụng của bạn làm gì ? Đây là một khởi đầu:

[TestFixture]
public class RegistrationTests
{
    [Test]
    public void Should_save_new_user_info()
    {
    }

    [Test]
    public void Should_throw_validation_exception_when_email_already_exists()
    {
    }

    [Test]
    public void Should_format_phone_number_when_country_code_is_us()
    {
    }
}

Chỉ tạo một dự án thử nghiệm và viết một số phương thức thử nghiệm là một loại TDD, nhưng theo kinh nghiệm của tôi, nó không giúp ích được gì trừ khi bạn đang làm việc trên một thư viện nơi có các lệnh gọi API và phương thức tương ứng trực tiếp với thứ mà người dùng mong đợi . Bạn cần đưa ra danh sách các bài kiểm tra phù hợp và đối với một ứng dụng không tầm thường, điều đó có thể thực sự khó thực hiện.

Tôi khuyên bạn nên thử SpecFlow - nó tiếp tục xác định các kiểm tra tách biệt với việc triển khai và cấu trúc của các tệp tính năng buộc bạn phải suy nghĩ về những gì bạn đang thực sự kiểm tra.

Khi bạn xác định một tính năng, bạn chỉ cần viết một cái gì đó như

When a user is saved
Then the user should exist

Vì tại thời điểm này, bạn không có tệp mã, nên bạn không muốn nghĩ về các chi tiết triển khai như phương thức nào được gọi để tạo người dùng hoặc thậm chí lớp nào được triển khai. Bạn có thể sử dụng thẻ để chọn các triển khai khác nhau, Vì vậy, ở cấp độ này, không quan trọng việc "người dùng được lưu" có nghĩa là một cuộc gọi đến CreatUser hoặc mở trình duyệt và gửi biểu mẫu.

Khi bạn đã xác định các tính năng, tất cả các thử nghiệm được tạo và sẽ bắt đầu vượt qua khi bạn triển khai các định nghĩa bước và mã ứng dụng thực tế đang được thử nghiệm.

Đối với một ứng dụng đơn giản, bạn chỉ có thể tạo các tệp tính năng, nhưng đối với bất kỳ điều gì phức tạp hơn, sẽ rất hữu ích khi kết hợp một thông số kỹ thuật đầy đủ hơn trước đó. Tôi sử dụng một ứng dụng mindmapping iPad cho việc này, nhưng bạn có thể sử dụng bất kỳ công cụ nào bạn thấy thoải mái nhất.

Bắt đầu với một danh sách các tính năng cấp cao như "Đăng ký người dùng". Chúng có xu hướng quá rộng để viết các bài kiểm tra trực tiếp, vì vậy hãy chia chúng thành các tính năng phụ có thể được xác định rõ ràng và thường ánh xạ tới một hành động người dùng cụ thể như "Lưu người dùng" hoặc "Xem người dùng hiện tại".

Mỗi tính năng phụ này sẽ cần một danh sách các kịch bản cùng nhau xác định hoàn toàn tính năng này có hoạt động hay không, những thứ như "Có thể lưu người dùng hợp lệ" và "Không thể lưu người dùng với tên người dùng trùng lặp".

Khi bạn xây dựng danh sách này, nó sẽ trở nên rõ ràng nơi cấu trúc cần được điều chỉnh - nếu bạn không thể đưa ra bất kỳ thử nghiệm kịch bản nào cho một tính năng hoặc bạn kết thúc với quá nhiều tính năng trong một tính năng thì tính năng đó có thể được xác định tại mức độ sai và cần phải được chia hoặc thay đổi.

Tôi thấy thật tốt khi sao lưu các thử nghiệm đầu tiên của mình vào TDD với một số cách đọc cũng như cắt mã. Các bài viết wikipedia về chủ đề này là rất tốt và sẽ dẫn bạn một loạt các nguồn lực khác. Tìm kiếm những thứ của Kent Beck nói riêng - loại cha đẻ của TDD.

Một điều khác có thể giúp bạn vượt qua nó là thực hiện một số katas - những bài tập huấn luyện đơn giản, gần như không cần suy nghĩ. Roy Osherove có một số người tốt.

Ngoài ra, chỉ cần ghi nhớ các ý tưởng chính của TDD - viết một bài kiểm tra tại một thời điểm và không tiếp tục cho đến khi nó và tất cả các bài kiểm tra trước đó vượt qua. Chỉ viết đủ mã để đáp ứng bài kiểm tra hiện tại, tránh sự cám dỗ để viết nhiều hơn. Khi bạn đi, dừng lại mọi lúc và suy nghĩ nếu bạn có thể dọn sạch mã hoặc các bài kiểm tra. Luôn luôn phát triển trong một màu đỏ (thử nghiệm thất bại), màu xanh lá cây (vượt qua thử nghiệm), chu kỳ tái cấu trúc.

Và để giúp bạn bắt đầu, có lẽ bắt đầu với yêu cầu tên của bạn. Bạn sẽ cần gì?

Bạn có thể sẽ cần một lớp học. Viết một bài kiểm tra cho điều đó (một số người bỏ qua điều này nhưng khi bắt đầu làm nó cho bài tập) và viết lớp.

Tiếp theo lớp của bạn sẽ cần lưu trữ một tên. Viết một bài kiểm tra chứng minh rằng lớp học của bạn thực sự có thể. Sau đó lại viết mã để thực hiện bài kiểm tra.

Sau đó, có lẽ bạn có một số quy tắc kinh doanh hơn. Có lẽ bạn muốn tên của bạn dài một số ký tự. Viết bài kiểm tra, xem nó thất bại, viết mã.

Và như thế...

Tôi nghĩ rằng không thể cung cấp cho bạn ý tưởng về TDD trong một câu trả lời ngắn. Bạn cần phải "nhìn" sombody thực hành nó, để có được cảm giác của nó. Tài nguyên tốt nhất tôi từng tìm thấy về chủ đề đó là http://pragprog.com/title/achbd/the-rspec-book . Trước khi bạn nói với tôi, rằng Ruby không phải là ngôn ngữ của bạn: Đọc lời tựa của chú Bob! ;-)

Bạn có thể muốn thiết lập một thử nghiệm cố gắng thêm nhiều giá trị khác nhau vào trường email, một số có giá trị và một số khác thì không. Đừng ngừng phát triển cho đến khi tất cả các thử nghiệm cho giá trị mong đợi. Những thứ như thế.

Như bạn đã mô tả hệ thống, chỉ có một thử nghiệm ở cấp ứng dụng:

[Kiểm tra] void void Save_and_retrieve_user (Tên chuỗi, Email chuỗi, ...) {// Lưu // Lấy // Xác minh}

Khi bạn tinh chỉnh các yêu cầu, thêm nhiều bài kiểm tra.