Search code examples
ruby-on-railscucumberguard

Guard-cucumber: watch on view and controller related to feature


Cucumber stands for acceptance testing framework. So BDD in cucumber assumes working with controllers and views.

But surprisingly guard-cucumber does not offer approach for running feature if controller or view files (related to this feature) have been changed.

Feature and scenario could be tagged. How I can use tags named by controller in this case?


Solution

  • The idea of BDD is to drive the development from the outside to the inside, meaning that you start by describing the feature from the outside with Cucumber. From the outside you do not have an idea about the inner workings of the software, so you don't know anything about controllers or view files in Cucumber. To communicate with the application from the outside, you use the provided interface, e.g. a CLI interface or a web interface. Given a web interface, you describe the outside in terms of browsing the web: you navigate to urls, you press links and buttons, fill in forms and verify the outcome by looking at the web page.

    In the BDD cycle you describe the feature from the outside, but to implement it you need to go to the inside, where you drive your development with another testing framework like RSpec. When working in the inside loop, you write model, controller and view test to drive your implementation, and when both the inner test loop and the outside test loop is green, you've successfully implemented your feature.

    Guard::RSpec and Guard::Cucumber doesn't provide an out of the box implementation for outside-in development, but you can use the Guard API to achieve it:

    guard :rspec do 
      # ... your normal rspec guard config goes here
    
      # run cucumber after rspec passes
      callback(:run_all_end) do
        unless Guard.guards(:rspec).last_failed
          Guard.run_all({ :guard => Guard.guards(:cucumber) })
        end
      end
    end
    

    This glue code triggers Cucumber when all RSpec specs are green, passing the focus back to the outer loop. Of course you can enhance this to have more fine grained control over the features that are run, but this heavily depends on a proper naming schema for your feature/spec files and directories.