Rake is Ruby Make. For folks who have worked on *nix based systems (Unix, Linux etc.) , make is a classic build scripting language/tool used so extensively to do system level programming and kernel rebuilding and so on so forth. Rake is an extremely powerful gem that Ruby provides to automate build tasks. For Java folks, think about Ant, Maven, Gradle etc. A gross generalization of build scripting tools would be to categorize into “convention” based tools vs. “configuration” based tools. In short convention means, the tools pretty much dictates a workflow and standard a user has to follow and there is a lifecycle. Configuration on the other hand lets a user expand wings and do more than what is provided out of box. There are pros and cons of each type, anyways that is NOT a discussion on this forum. You can always search and read more.
I would like to compare Rake with more of Gradle, where we can have both convention and configuration capabilities based on needs. In Ruby world, rake is very commonly used both on RoR development and test Automation tasks, builds and pretty much any set of activities to do by wrapping it up under a task. Read more if you are interested.
How is it useful here ?
To begin with, we can define tasks in rake and that can be an entry point for us to kick off execution. Let’s say over time, we have different configuration settings for each type of execution (Maybe we want to execute all features at one point and then we may want to execute all features with certain tags AND yet another time we may want to execute with certain cucumber profiles and settings)
As we mature with more and more cucumber scenarios being added and projects grow in size (and maybe we have multiple cucumber projects across teams), rake would help ease the situation to provide a start point to kick off execution.
Enough said !
In our watir_cucumber_ruby template project, at the root of the project, we would find a file named ‘Rakefile’. This Rakefile contains all tasks and the logic inside each task. There are lot of parameters and options, however here we are going to talk about a specific rake task that is Cucumber::Rake::Task
By default, we have a task named :default , that executes ‘cucumber features’ upon execution. So how do I execute?
List All Rake Tasks on project
From the project root directory, execute the below.
Create a Cucumber Rake task
Create a task that executes all @beta3 tagged scenarios and copy the below code in ‘Rakefile’
Cucumber::Rake::Task.new(:beta3) do |t|
t.profile = 'default'
t.cucumber_opts = '--tags @beta3'
Now whenever we execute “rake beta3” from the project root folder, it is equivalent to executing “cucumber features –tags @beta3” from command line
t.cucumber_opts = '--tags @beta3'
Introspecting a little bit, the line “t.cucumber_opts” represents the cucumber options we have inside the file “cucumber.yml”. In the section Tag Scenarios, we observed how to execute scenarios associated with tags. One of the options for us was to append “–tags @beta3” to the default profile in cucumber.yml file. In the rake task above, we are exactly doing the same but now we are programmatically doing it by constructing a Cucumber rake task. This will lend us immense power to be able to send configuration parameters to the task and change the settings by defining it at task level and NOT hard-coding them in cucumber.yml.
When we talk about Frameworks beyond and patterns when we tie all things together, we will explain how a rake pattern described here is implemented in code and how flexible we can be to make changes to our project at runtime.
Run Rake task
rake beta3 (from the project folder where Rakefile exists) – That is it !
It is very difficult to capture the awesomeness of rake in this one post, however I hope you got a flavor of what Rake can do. We probably uncovered < 1% of what rake can do. If you are intrigued, go figure it out on internet. Happy ‘Rake power!’