_edited_edited.png)
GitHub:
GitHub is a platform for hosting software. It's designed primarily for hosting source code, meaning the "raw," uncompiled code that is used to build applications. You can also upload, store, and share binary files (such as compiled applications or images) on GitHub if you wish, but it's more common to use binary repositories for this purpose; for example, if you want to store and distribute container images, you could use Docker Hub.
GitHub's core features include support for:
Storing source code
Tracking changes to source code over time
Sharing code with other developers or end users, if desired
GitHub provides these features by allowing programmers to configure repositories. Typically, each repository is dedicated to a specific software project; for example, if you're building multiple applications, you'd generally create a separate repository for each of them. You can then upload and store the various files associated with each project — source code files, configuration data, documentation, and so on — in the repository. Whenever you modify a file or replace it with a new one, GitHub automatically keeps track of the version changes.
Features of GitHub?
There are many reasons to take advantage of GitHub:
Social coding: GitHub is sometimes called a social coding platform because it lets developers collaborate easily when building software. Even if you don't specifically need to collaborate with other coders, sharing your code on GitHub allows other developers to inspect, download, and (if you give them permission) even modify your code, if they wish.
Version control: As noted above, GitHub automatically tracks versioning changes to code.
Code review: GitHub makes it easy to review your own code, as well as code written by others. You can leave comments to explain why you made a certain change, for instance, or suggest a way to improve code.
Code sharing: By configuring public repositories, you can use GitHub to share code with anyone who may want it.
Documentation: Although GitHub isn't a complete documentation tool on its own, developers can use it to manage documentation files in addition to code.
Because GitHub is hosted on the internet, it can be accessed from anywhere. In addition, multiple developers can work on code in the same repository at once — a feature that is beneficial for projects where more than one coder is developing software. GitHub automatically monitors which developers made which changes to data inside repositories, so you get a record not just of how your versions have changed over time, but also who was responsible for the changes. And you can revert changes made by a specific developer, or changes associated with a certain version, whenever you want.
GitHub repositories can be either public (meaning that anyone on the internet can view and download code hosted in them) or private (which means they are available only to specific users). Public GitHub repositories are a great way to host open source code, while private repositories are useful if you want to build software that should be available only to developers inside your organization or a select group of external users.
How does GitHub work?
We touched on GitHub's core features above, but let's take a deeper look at how GitHub's features work.
GitHub for version control
Version control is a standard GitHub feature that is enabled by default, for free. Using version control, you can view changes to code over time. Each change (or set of changes) is known as a commit, and you can track how your code evolves as various developers make commits.
Beyond being able to see how your code has changed, you can use GitHub version control to revert to an earlier version of your code if you introduce a change that causes a bug, for example. You can also make multiple versions of your software available at the same time, which is useful if, for instance, some of your users want to run the "beta" version of your application while others prefer a fully tested, stable version.
Collaboration and social networking for developers
Although it would be a stretch to call GitHub a social media platform in the traditional sense of the term, it offers collaboration features that help developers network with each other.
Developers can, for instance, search through GitHub to find projects — and the programmers associated with them — that are of interest to them. Developers can also configure GitHub profile pages to share information about themselves. And, although you can't send messages directly through GitHub, it's a common practice for coders to share their contact information on their GitHub pages so that others can contact them if they wish.
Web-based version control
GitHub provides a convenient way of managing code through a web interface.
As noted above, most of GitHub's core functionality derives from Git. Functionally speaking, most of the things you can do in GitHub could also be done using Git on a command line.
However, it can be challenging to use Git on the command line when you have dozens of repositories to manage and multiple developers working across them. By allowing developers to view the contents of repositories, open up individual files, track changes, and much more directly through a web browser, GitHub provides convenience. It also makes version control more scalable.
Distributing code
GitHub is a great solution not only for making code available to end users, but also for developers who want to share their code with other developers in order to invite their feedback or ask them to collaborate.
GitHub is particularly useful for managing open source projects, since open source coders are typically eager for the community at large to build and use their code — and for outsiders to contribute to their projects, if they have the inclination.
That said, GitHub isn't strictly just for open source projects. You can also set up private repositories if you want to manage proprietary code in GitHub.
Note, too, that although GitHub is widely used for hosting open source projects, most of the code behind GitHub itself is not actually open source. For that reason, developers who are ideologically committed to open source software — who, in other words, believe that software should be open source as a matter of principle — may prefer to use a GitHub alternative that is fully open source, like GitLab.
Best Practices for Getting the Most Out of GitHub
You should check out the resources described above for full details on GitHub best practices. But if you're new to GitHub, some basic best practices to keep in mind include:
Create a repository for each project: Although it may be simplest to create one repository for all of your code, projects are much more manageable if each one has its own repository.
Test before making pull requests: Before you submit a pull request, carefully vet your code to increase the chances that the developers you're submitting to will accept your request.
Use descriptive commit messages: Whenever you make a change to code in GitHub, include a comment explaining why you did it. Other developers — not to mention your future self — may want to understand your thinking.
Don't use GitHub as a backup service: Although you technically could store data that you want to back up using GitHub, that's not what GitHub is designed for. It's also not especially cost-effective for large-scale data backup storage. Use a dedicated backup storage platform if you need to back up information.
Don't use GitHub to host binaries: Likewise, GitHub is not intended to be a place to host application binaries. Store those in a binary repository or container registry, and use GitHub for your source code.
Gherkins:
Gherkin is the language used by Cucumber tool. It is a simple English representation of the application behavior. Cucumber uses the concept of feature files for documentation purposes. Content within the feature files is written in Gherkin language.
Cucumber Gherkin framework uses certain keywords that are essential for writing a feature file.
The following terms are most commonly used in feature files:
#1) Feature:
A feature file must provide a high-level description of an Application Under Test (AUT). The first line of the feature file must start with the keyword ‘Feature’ following the description of an application under test. As per the standards prescribed by Cucumber, the feature file must include the following three elements as the first line.
Feature Keyword
Feature Name
Feature Description (optional)
The feature keyword must be followed by a feature name. It can include an optional description section that can span across multiple lines of the feature file. A feature file has the extension .feature.
#2) Scenario:
A scenario is a test specification of the functionality to be tested. Ideally, a feature file can contain one or more scenario as a part of the feature. A scenario includes multiple test steps. As per the cucumber standards, a scenario must include 3-5 test steps as lengthy scenarios tend to lose their expressive power once the number of steps increases.
A scenario can include the following steps:
Action to be performed by a user.
Expected Results of the action.
In Gherkin language, a scenario must include the following keywords:
Given
When
Then
And
Given:
Given keyword is used to specify the preconditions for executing a specific scenario. A scenario may include more than one Given statements or there can be no Given statements for a scenario.
When:
This keyword is used to specify the action or an event performed by the user such as clicking on a button, entering data onto textbox etc. There can be multiple when statements in a single scenario.
Then:
Then keyword is used to specify the expected outcome of an action performed by the user. Ideally, When keyword must be followed by Then keyword to understand the expected result of user actions.
And:
And keyword is used as a conjunction keyword to combine multiple statements. For Example, multiple Given and When statements in a scenario can be combined using the keyword ‘And’.
#3) Scenario Outline:
A scenario outline is a way of parameterization of scenarios.
This is ideally used when the same scenario needs to be executed for multiple sets of data, but the test steps remain the same. Scenario Outline must be followed by the keyword ‘Examples’, which specify the set of values for each parameter.
Below is the example to understand the concept of Scenario Outline:
Example:
Scenario Outline: Upload a file
Given that a user is on upload file screen.
When the user clicks on the Browse button.
And user enters <filename> onto upload textbox.
And user clicks on the enter button.
Then verifies that file upload is successful.
Examples:
|filename|
|file1|
|file2|
Parameters within the scenario outline must be specified with the characters ‘<’ and ‘>’. A list of data values for the parameter must be specified using the Pipe (|) symbol.
#4) Background:
Background keyword is used to group multiple given statements into a single group.
This is generally used when the same set of given statements are repeated in each scenario of a feature file. Instead of specifying the given statements for each scenario repeatedly, they can be specified with the keyword ‘Background’ before the first scenario.
Example:
Background:
Given user is on the application login page
Comments