Cách sắp xếp định nghĩa thông số kỹ thuật trong Dưa chuột?

Question

Chúng tôi đang xem xét sử dụng Dưa chuột trong dự án của chúng tôi để thử nghiệm chấp nhận.

Khi chúng tôi viết một scenario trong một Dưa chuột feature, chúng tôi viết một danh sách các Given, When và Then báo cáo.

Khi chúng tôi sử dụng dự án cucumber-jvm, câu hỏi Given, When và Then có liên quan đến các phương thức Java trong (JUnit) lớp học.

Tôi muốn biết tổ chức tốt nhất cho mã liên quan đến Given/When/Then trong cấu trúc dự án là gì. Mối quan tâm chính của tôi là duy trì các bài kiểm tra dưa chuột trên một dự án lớn, trong đó số lượng kịch bản khá quan trọng và đặc biệt là các mục được chia sẻ giữa các tính năng.

tôi có thể thấy ít nhất 2 phương pháp chính:

1. Mỗi tính năng có liên quan đến lớp JUnit riêng của nó. Vì vậy, nếu tôi có một tệp dưa chuột foo/bar/baz.feature, tôi sẽ tìm thấy lớp học foo.bar.Baz JUnit được bổ sung với các phương thức được chú thích đầy đủ @Given, @When và @Then.

2. Cách ly @Given, @When và @Then các phương pháp thành các lớp và gói "chuyên đề". Ví dụ, nếu trong kịch bản dưa chuột của tôi, tôi có tuyên bố Given user "foo" is logged thì phương thức chú thích @Given("^user \"([^\"]*)\" is logged$") sẽ được đặt trong phương thức lớp foo.user.User, nhưng có khả năng, phương pháp @When được sử dụng sau trong cùng một kịch bản dưa chuột sẽ nằm trong một lớp và gói Java khác (giả sử foo.car.RentCar).

Đối với tôi, cách tiếp cận đầu tiên có vẻ tốt theo cách tôi có thể dễ dàng thực hiện mối quan hệ giữa các tính năng dưa chuột và mã Java của tôi. Nhưng nhược điểm là tôi có thể có rất nhiều dư thừa hoặc sao chép mã. Ngoài ra, khó có thể tìm ra phương pháp @Given hiện có, để tránh tạo lại nó (IDE có thể giúp, nhưng ở đây chúng ta đang sử dụng Eclipse, và nó dường như không đưa ra một danh sách câu lệnh Given hiện có?).

Cách tiếp cận khác có vẻ là tốt hơn về cơ bản khi bạn có Given điều kiện được chia sẻ giữa một số tính năng dưa chuột và do đó tôi muốn tránh trùng lặp mã. Hạn chế ở đây là khó có thể tạo liên kết giữa phương thức Java @Given và câu lệnh dưa chuột Given (có thể, một lần nữa, IDE có thể trợ giúp?).

Tôi khá mới để dưa chuột, vì vậy có lẽ câu hỏi của tôi không phải là một câu hỏi hay, và với thời gian và kinh nghiệm, cấu trúc sẽ hiển nhiên, nhưng tôi muốn nhận được phản hồi tốt về cách sử dụng của nó ...

Cảm ơn.

Answer 1

Chúng tôi cũng đã bắt đầu sử dụng Cucumber-JVM để kiểm tra nghiệm thu và có vấn đề tương tự với việc tổ chức mã. Chúng tôi đã chọn có một lớp định nghĩa 1 bước cho mỗi tính năng. Tại thời điểm này là tốt như các tính năng chúng tôi đang thử nghiệm không phải là rất phức tạp và khá riêng biệt, có rất ít chồng chéo trong các tính năng của chúng tôi.

Cách tiếp cận thứ hai mà bạn đề cập sẽ tốt hơn tôi nghĩ, nhưng thường khó để kết hợp các lớp định nghĩa bước khác nhau cho một kịch bản duy nhất. Tôi nghĩ rằng cấu trúc dự án tốt nhất sẽ trở nên rõ ràng hơn khi bạn bắt đầu thêm nhiều tính năng và refactor như bình thường.

Trong khi đó đây là một plugin của Eclipse cho dưa chuột,

https://github.com/matthewpietal/Eclipse-Plugin-for-Cucumber

nó có nổi bật cú pháp cũng như một danh sách các hiện bước có sẵn khi viết một tính năng.

Answer 2

Tôi khuyên bạn nên nhóm mã của mình theo các đối tượng mà nó đề cập đến, tương tự như tùy chọn # 2 bạn đã trình bày trong câu hỏi của mình. Lý do là:

• Cấu trúc mã của bạn dựa trên cách thức và nơi sử dụng mã không lớn. Nó thực sự tạo sự liên kết giữa các tệp tính năng và mã của bạn.
  Hãy tưởng tượng một thứ như vậy trong mã sản phẩm của bạn- chức năng SendEmail() sẽ không nằm trong một lớp được gọi là NewEmailScreenCommands, phải không? Nó sẽ là trong EmailActions hoặc một số như vậy.
  Vì vậy, điều tương tự cũng áp dụng ở đây; cấu trúc mã của bạn theo những gì nó làm, và không phải ai sử dụng nó.

• Cách tiếp cận đầu tiên sẽ gây khó khăn cho việc sắp xếp lại các tệp tính năng của bạn; Bạn sẽ phải thay đổi các tệp mã của mình bất cứ khi nào bạn thay đổi các tệp tính năng của mình.

• Giữ mã được nhóm theo chủ đề khiến cho việc tạo mã dễ dàng hơn nhiều; bạn biết chính xác nơi mà tất cả mã giao dịch với thực thể user là, vì vậy bạn dễ dàng sử dụng lại mã đó hơn.

Mở dự án của chúng tôi, chúng tôi sử dụng phương pháp đó (nghĩa là BlogPostStepDefinitions lớp), với hơn nữa tách mã, nếu lớp trở nên quá lớn, để loại bước (nghĩa là BlogPostGivenStepDefinitions).

Answer 3

Trong dự án hiện tại tôi đang tham gia, chúng tôi đã tự hỏi chính câu hỏi đó.

Sau khi sử dụng một chút với các khả năng, những gì chúng tôi đã chọn là kết hợp cả hai giải pháp bạn đã tiếp xúc.

• Có bước tập hợp lại trong các lớp bước chung chủ đề trung tâm
  • ứng dụng khởi động bước
  • kiểm tra an ninh bước
  • [nơi tính năng ngẫu nhiên mối quan tâm ở đây] bước
• Và lớp học của kịch bản (và trong một số trường hợp thậm chí tính năng) các bước cụ thể

Điều này là để có cùng một lúc nhóm các mã số yếu tố đó là khá dễ dàng nhận dạng trên đó là whatabouts, nơi ở và whatnot. Tuy nhiên, nó cho phép không làm lộn xộn những lớp phổ biến với mã quá cụ thể.

Sự kết nối giữa tất cả các lớp này được xử lý bởi lò xo (với mùa xuân dưa chuột, một công việc tuyệt vời khi bạn nhận được công việc của nó).