Thực hành tốt nhất D3 và TDD

Question

Điều nào mang lại nhiều lợi thế hơn cho một phần mềm lớn, ví dụ như Photoshop?

Cũng bởi TDD Tôi không có nghĩa là chỉ đơn vị kiểm tra, bởi vì bạn có thể sử dụng các bài kiểm tra đơn vị trong D3 quá, chỉ cần không giống như cách TDD nào.

D3: Thiết kế Driven Development

TDD: Test-Driven Development

Answer 1

Tôi cũng không nghĩ rằng họ đang loại trừ lẫn nhau Tôi nghĩ rằng bạn có thể sử dụng TDD để có được DDD.

Answer 2

DDD = Domain Driven Thiết kế

TDD có nghĩa là trước khi bạn viết bất kỳ đơn vị của hành vi bạn có một thử nghiệm cho hành vi này và chỉ hành vi này. Chỉ sau khi các thử nghiệm này không thành công, bạn thực hiện hành vi. Trong mọi hiện thân mà tôi đã nhìn thấy TDD đã được trên mức độ của một phương pháp hoặc lớp học - có thể là một vài lớp học làm việc cùng nhau. Kết quả cuối cùng là bạn nhận được mã có khả năng kiểm tra cao và do đó rất lỏng lẻo. Cuối cùng, mặc dù TDD là về việc tạo mã có thể được kiểm tra.

DDD là một triết lý trừu tượng hơn nhiều và tập hợp các mẫu thiết kế giải quyết cách thiết kế một hệ thống lớn, có thể mở rộng và có thể duy trì. Cuối cùng DDD là về việc tạo ra một hệ sinh thái mã mà ngầm hoặc nắm bắt một cách rõ ràng các bit quan trọng của kiến ​​thức miền.

Vì vậy, bạn thấy, chúng chắc chắn không loại trừ lẫn nhau. Khá nhiều người mà tôi biết ai am hiểu về DDD cũng là một người đam mê TDD cốt lõi.

Answer 3

TDD không phải là từ dưới lên cũng như viết các bài kiểm tra trước khi viết mã. TDD là về việc sử dụng các thử nghiệm để thúc đẩy sự phát triển với mục tiêu là mã được kiểm tra trước khi giao hàng. Bắt đầu bằng việc đảm bảo rằng các yêu cầu của người dùng được viết bằng một biểu mẫu giúp cho việc kiểm tra chấp nhận tự động của người dùng có thể được thực hiện. Nó tiếp tục thông qua tích hợp và kiểm tra chức năng xuống để kiểm tra đơn vị. Thử nghiệm đơn vị tạo thành phần của sư tử cuối cùng.

Lý do tại sao các bài kiểm tra nên được viết đầu tiên là vì khi một giải pháp cho một vấn đề được xem xét (được thiết kế), bạn sẽ tự động mong đợi giải pháp nên làm gì. Bất kỳ kỳ vọng nào có thể được thể hiện dưới dạng thử nghiệm, vậy tại sao không lập tức ghi lại kỳ vọng và đồng thời có một thử nghiệm tự động cho nó để đảm bảo giải pháp đạt được mục tiêu đó?

Answer 4

Theo ý kiến ​​của tôi khi bạn viết bài kiểm tra đầu tiên (trong TDD), bạn đang thiết kế hệ thống. Nếu chúng ta không thể viết các bài kiểm tra trước, nó cho thấy có sự mơ hồ trong yêu cầu. Chúng tôi có thể viết câu chuyện trước khi kiểm tra và sử dụng nó như là đặc điểm kỹ thuật được biết đến Test As Specification. Sau khi vượt qua các bài kiểm tra, chúng tôi có thể sử dụng các bài kiểm tra làm tài liệu đã biết Test As Document. Khi các nhà phát triển mới được thêm vào dự án, họ có thể sử dụng các bài kiểm tra này để tìm hiểu về kinh doanh hệ thống.

Trong DDD bạn chỉ sử dụng câu chuyện để tạo mối quan hệ giữa các đối tượng. Điều quan trọng trong DDD là bạn chỉ nên tập trung vào miền. Ví dụ khi viết logic nghiệp vụ miền, bạn không nên lo lắng về việc lưu các thực thể trên cơ sở dữ liệu. Trong ngắn hạn, bạn không nên nghĩ về bất cứ điều gì bên ngoài các lĩnh vực khi viết logic kinh doanh.