2010-12-13 12 views
7

Tôi đang lên kế hoạch tạo plugin sẽ tạo mã ứng dụng dựa trên kịch bản dưa chuột, nhưng tôi muốn đảm bảo rằng tôi không sáng tạo lại bánh xe ở đây. Có ai biết về một plugin hoạt động với Cucumber và tạo ra các mô hình, bộ điều khiển và chế độ xem không?Có bất kỳ plugin Rails nào có thể tạo mô hình, chế độ xem, v.v ... sử dụng các kịch bản Cucumber không?

Chỉ cần một chút thông tin về những gì tôi đang cố gắng làm trong trường hợp điều này không có ý nghĩa. Khi tôi tạo một ứng dụng mới ở đây là quy trình làm việc của tôi:

  1. Phác họa 2 loại thiết kế cấp cao trên bảng trắng của tôi. 1 hiển thị các mô hình và mối quan hệ và mô hình khác hiển thị một số màn hình nguyên thủy cho bố cục, biểu mẫu, v.v.

  2. Viết kịch bản dưa chuột dựa trên thiết kế cấp cao (nhưng mịn hơn). Nhiều bước trong số này chỉ mô tả những gì tôi sẽ thấy trên một chế độ xem cụ thể và cũng phác thảo luồng của ứng dụng. Tôi thấy rằng việc tạo ra tất cả các kịch bản mà tôi có thể nghĩ ra trước khi tôi bắt đầu viết mã là tốt hơn so với thực hiện từng cái một và viết mã sau khi viết từng kịch bản.

  3. Tôi chạy các kịch bản dưa chuột và nhìn vào lỗi đầu tiên và bắt đầu mã hóa từ đó. Tôi thường có một số thiết lập bổ sung trước khi bước này để cấu hình ứng dụng Rails của tôi để sở thích của tôi và bao gồm đá quý mà tôi biết tôi sẽ sử dụng. Tôi cũng tìm thấy một thứ tự hợp lý để chạy các tệp tính năng của mình vì một số tệp phụ thuộc vào các tệp khác. Rõ ràng bắt đầu với những thứ như xác thực.

  4. Sau đó, tôi sử dụng trình tạo Rails (giàn giáo hoặc chỉ mô hình) để giúp tôi tạo mã mà tôi cần để truyền một kịch bản. Tôi thay đổi một số mẫu máy phát để cung cấp cho tôi những gì tôi muốn.

  5. Sau đó, tôi tinh chỉnh mã được tạo nếu cần. Phần lớn thời gian này liên quan đến việc thiết lập các mối quan hệ trong mô hình, làm việc với các liên kết trong khung nhìn và bất kỳ chức năng không chuẩn nào khác mà giàn giáo không thể cung cấp.

  6. tôi chạy di cư của tôi nếu cần thiết

  7. Sau đó, tôi chạy lại kịch bản của tôi và lặp lại bất kỳ bước trong 4-6 cho đến khi kịch bản đi.

  8. Lặp lại các bước 4-7 cho đến khi tất cả các tình huống đều trôi qua.

Tôi có thể sai, nhưng tôi nghĩ rất nhiều người có thể sử dụng cách tiếp cận tương tự như vậy. Điều làm tôi khó chịu là tôi thấy rất nhiều sự trùng lặp giữa việc viết kịch bản và tạo/chỉnh sửa mã. Tôi muốn để có thể tạo ra các skelaton của ứng dụng của tôi với các kịch bản dưa chuột của tôi và sử dụng các định nghĩa bước để giúp tôi tùy chỉnh những gì được tạo ra. Dưới đây là một ví dụ:

Scenario: MODEL widget exists 
    Given a widget model exists 
    Then it should belong to a "manufacturer" 
    And it should have a "quantity:integer" field 
    And it should validate the presence of "quantity" 
    And it should have many "wadgets" 
    And it should accept nested attributes for "wadgets" 
    #etc... 

Scenario: VIEW new widget page 
    Given I am on the new widgets page 
    Then I should see a "quantity" field 
    And I should see a "wadgets:name" nested field 
    And I should see a button with text "Save Widget" 

Scenario: CONTROLLER widget is created 
    Given a new widget is created 
    Then I should be on the widgets page 

Điều này sẽ tạo ra mã như vậy:

#FROM SCENARIO 1 
class Widget < ActiveRecord::Base 
    has_many :wadgets 
    belongs_to :manufacturer 
    validates_presence_of :quantity 
    accepts_nested_attributes_for :wadgets 
end 

#FROM SCENARIO 1  
class CreateWidget < ActiveRecord::Migration 
    def self.up 
    create_table :widgets do |t| 
     t.integer :quantity, :null=>false 
     t.integer :manufacturer_id 

     t.timestamps 
    end 
    end 

    def self.down 
    drop_table :widgets 
    end 
end 

#FROM SCENARIO 2 
#new.html.haml (using formtastic helpers) 
=semantic_form_for(@widget) do |f| 
    = f.inputs do 
    = f.input :quantity 
    = f.semantic_fields_for :wadgets do |wadget| 
     = location.input :name 
    = f.buttons 
    =f.commit_button "Save Widget" 

#FROM SCENARIO 3 (using inherited resources) 
class WidgetsController < InheritedResources::Base 
    def create 
    create!{ widget_urls } 
    end 
end 

Đây chỉ là psuedo vào thời điểm này, nhưng tôi nghĩ rằng nó sẽ là một thời gian thực-saver để xác định ứng dụng của bạn trong Các kịch bản dưa chuột và sau đó tạo mã dựa trên những gì trong các kịch bản này. Điều này sẽ cho phép bạn tạo các bài kiểm tra và viết mã cùng một lúc. Và bạn sẽ không phải loại bỏ tất cả các trường cho dòng lệnh của trình tạo giàn giáo, và nó sẽ tự động thiết lập các liên kết và tạo các kiểu trường thích hợp trong khung nhìn. Ngoài ra, nó sẽ cho phép bạn giữ toàn bộ thiết kế tính năng trong một tệp.Sử dụng phương pháp này, bạn sẽ chạy máy phát điện đầu tiên trên kịch bản và sau đó chạy thử nghiệm dưa chuột sau khi tạo. Nếu nó được thiết lập chính xác, mọi thứ sẽ vượt qua lần đầu tiên và bạn sẽ có một nguyên mẫu khá chắc chắn mà bạn có thể tùy chỉnh.

Có bất kỳ plugin nào giống với loại thử nghiệm này kết hợp thế hệ & không?

Và cảm ơn nếu bạn đã dành thời gian để đọc điều này .. Tôi biết nó là một chút dài.

+0

Tôi nghĩ rằng đây khá một ý tưởng thú vị, tôi Recon nó sẽ là một công việc cho Ragel – scaney

+0

Wow, đây là một ý tưởng tuyệt vời! Tôi đã không nghe nói về bất cứ điều gì mà làm điều này. Nếu bạn đi trước với kế hoạch của bạn, tôi sẽ rất quan tâm đến việc sử dụng plugin này và có lẽ đóng góp là tốt. Tôi hy vọng bạn sẽ blog rộng rãi về điều này và thậm chí có thể ping Ryan Bates để ông có thể làm một Railscast về nó, qua đó đảm bảo tiếp xúc với số lượng lớn của cộng đồng Rails. – Samo

+0

@Samo - Tôi đang làm việc trên một nguyên mẫu đơn giản ngay bây giờ, cố gắng tìm ra các ins and outs .. và tôi có lẽ sẽ viết blog về nó trong tuần tới hoặc 2. Tôi sẽ gửi cho bạn một liên kết đến repo github sau Tôi đặt một số công việc vào nó và xem nếu một cái gì đó bạn muốn giúp đỡ. Cảm ơn! – johnmcaliley

Trả lời

2

Tôi nghĩ việc bạn sử dụng dưa chuột ở đây không giống như dự định.

Tôi giả sử tất cả chúng ta đồng ý rằng tính năng dưa chuột nên mô tả các tính năng nhất định mà khách hàng muốn xem - về cơ bản dịch thẻ câu chuyện (yêu cầu) thành thử nghiệm runnable. Những câu chuyện này không nên quan tâm đến việc triển khai các mô hình, bộ điều khiển và chế độ xem của bạn. Nó nên kiểm tra những thứ như "khi tôi nhấp vào nút X, tôi nên được đưa đến trang Y, và trình của tôi nên được chấp thuận." Nó chỉ là một thử nghiệm tích hợp lớn mô phỏng sự tương tác giữa người dùng và trang web của bạn. Trong ví dụ của bạn, bạn tìm kiếm các trường cụ thể trên trang, có thể được kiểm tra ngầm bằng cách nói "khi tôi điền vào trường số lượng với 5."

Để kiểm tra hành vi của các mô hình và cách chúng tương tác với logic nghiệp vụ, bạn nên sử dụng RSpec hoặc Test :: Unit - dễ dàng hơn để viết các kiểm tra và thực hiện mô phỏng. Tôi chắc rằng có các plugin tạo các kiểm tra RSpec cho từng trường/mối quan hệ trong mô hình của bạn. Các trình tạo đường rspec-ray đã đến hầu hết công việc cho bạn, ví dụ: rails generate rspec:scaffold Post

Tôi nghĩ cải thiện tốt nhất cho đường ống dưa chuột là để thử nghiệm mô hình và bộ điều khiển cho RSpec, nhưng sau đó có thể tạo các hành động CRUD chuẩn cho một tài nguyên nhất định với các tính năng dưa chuột được tạo, như "Người dùng phải có thể tạo ra một X. "

+0

Tôi thích bạn trả lời, không có plugin như vậy, và rõ ràng nó không phải là ý tưởng tốt, thử nghiệm tính năng cốt lõi ray chỉ nên xuất hiện khi nó thực sự là rất quan trọng như một số trường hợp đặc biệt. Viết bài kiểm tra cho mỗi phần cơ bản của ứng dụng sẽ có nghĩa là rất nhiều nỗ lực đó là vô ích - làm cho nhiều vấn đề hơn sau đó giải quyết mọi thứ. Viết các bài kiểm tra như vậy sẽ lặp lại mã từ các mô hình/bộ điều khiển/lượt xem nói cách khác, bất kỳ thay đổi nào trong một sẽ buộc thay đổi trong nỗ lực thứ hai, nhân đôi hoặc thậm chí gấp ba lần. – mpapis

3

Tôi đã có ý tưởng tương tự cách đây vài ngày. Tuy nhiên, sau khi suy nghĩ về nó một số chi tiết, tôi từ bỏ ý tưởng tạo ra các mô hình từ các tập tin tính năng. Thay vào đó, tôi đang chơi với một dsl tạo ra các mô hình/khung/tài nguyên bằng cách sử dụng trình tạo đường ray từ dsl.

Sau khi tôi nhận được công việc này, tôi đã suy nghĩ của hooking trong máy phát điện để tạo ra các tập tin tính năng dựa trên dsl này.

Tôi có một cành chạy mà mất đầu vào sau:

application :test do 
    model :survey do 
    attribute :name, :string 
    has_many :questions 
    end 
    model :question do 
    has_many :options 
    has_many :answers 
    belongs_to :survey 
    attribute :body, :string 
    end 
    model :option do 
    belongs_to :question 
    attribute :body, :string 
    attribute :selector, :string 

    end 
    model :result do 
    belongs_to :survey 
    has_many :answers 
    end 
    model :answer do 
    belongs_to :result 
    belongs_to :question 
    attribute :value, :string 
    end 
    gen 
end 

và in ra sau đây:

rails new test 
cd test 
rails generate model survey name:string 
rails generate model question survey_id:integer body:string 
rails generate model option question_id:integer body:string selector:string 
rails generate model result survey_id:integer 
rails generate model answer result_id:integer question_id:integer value:string 
Updating class: Survey 
    has_many:questions 
Updating class: Question 
    belongs_to:survey 
    has_many:options 
    has_many:answers 
Updating class: Option 
    belongs_to:question 
Updating class: Result 
    belongs_to:survey 
    has_many:answers 
Updating class: Answer 
    belongs_to:result 
    belongs_to:question 

Steve

Các vấn đề liên quan