kaleidoscope

As we saw in previous posts of this series  Commits  are the first-class citizens in Git worlds, not the  Branches . But, branch names do show up in our commit messages and a few more places. Moreover, build-pipelines and other agile tools are often set up to refer to branch names with predetermined patterns. Therefore, organizations set up some nomenclature around branch naming. Branch naming strategies are not the topic of this post, the topic is, how to change the branch name if it's not adhering to your organization's standards. Create the problem Let's first set up our problem case. Let's say we have a repo named  git-renaming  in local as well as remote Let's create a feature branch and name it incorrectly  git checkout -b feature/master-incorrect-name Let's commit a new file in this branch echo “file1” >> file1 && git add file1 && git commit -m “second commit” Let's push this branch with the wrong name to remote.  git push ...

In our previous post  Behavior Driven Development  we discussed BDD. Here, let's look at  Cucumber.  The flagship BDD framework for java, but not limited to Java. Why Cucumber As we saw in the previous post, until the Automation phase, BDD is all about discovering and formulating  behavioral scenarios  through collaboration. Its the automation phase, where things really happen. It would be easy if we could write these behavioral scenarios in plain English ( or another preferred spoken language ) and runtime could understand and execute those for us. This is where Cucumber comes to the rescue. Cucumber Cucumber is a framework that let us write application-behavioral-expectations in meaningful spoken-language-text using  Gherkin. Cucumber implementations are available in many programming languages as shown below. Courtesy — Cucumber.io supported programming languages NOTE: It's recommended (not mandatory) to choose an implementation for the same platform...

In  previous post  we had an overview of the Cucumber, Gherkin & feature file. Now let's see how to write test cases in feature files using Gherkin. Anatomy of a feature-file All non-blank lines in a  feature file  have to start with a valid  Gherkin keyword.  Some of them we discussed in the previous post. Here is the description of the main Gherkin keywords. Feature: The first Keyword in feature-file must be  Feature,  it must be followed by   : After  Feature:  cucumber ignores all the text and lines for processing until a line starting with either  Scenario ,  Background,  or  Scenario Outline  keyword is found. All the text in between is used only for reporting purposes.  The first line is used as the feature name, and the remaining lines (if present) are used as feature descriptions. Scenario: Scenario keyword must also be followed by  :  .  Any text after  :  in this ...