After creating some automated tests it is commonly discovered that the IDE (Interactive Development Environment) you chose to write the tests has a pretty good test running/reporting tool. It is easy to stop there and declare that whenever we need to run any tests we can simply let someone on the automation team know and they can run them on their computer. You may wonder why some people do the extra work of getting the tests to run somewhere else. Here are 5 reasons to not run automated tests on your machine:

1. Test results access

The purpose of a test is to find out if something is working or if there is a problem. A test is useless if you cannot view the results. Common questions after a test is ran: “What tests were ran?”, “What are the results of the tests?”, “When did you run the tests?”, “What were the errors from the failed tests”. When a test is ran on a private machine, that puts the burden on the person who ran them to communicate the results and answer all the questions. This may not seem too daunting until you consider you don’t know which people will be concerned about the result for that specific test run.

When the tests are ran from a central location that everyone has access too, it allows everybody to have access to the results. Any interested parties can see for themselves what the current results are.

2. Multiple user access

There may be someone working on a certain issue to correct a failing test, or someone who wants to verify that a certain part of the system doesn’t have any problems. These examples do not require a run of the full test suite, but does require certain specific tests to be ran. It could turn into someones full time job to run the tests and report results.

Making the tests available for everyone on a central machine allows for a self-serve environment. If someone needs to verify a certain test is still working they can easily check it. Simple as that, they don’t need to pull other people to help or try to get the tests downloaded and running on their machine.

3. Running tests in parallel

In the beginning stages of making automated tests you may have 5 tests. At this stage the idea of running them in parallel does not seem like a big deal. It does not take long for a test suite to grow from 5 to 100. If each test takes about 2 minutes then you are looking at over 3 hours of tests. You could try to run them in parallel on your local machine but with tools like selenium running more than one at a time causes it to trip over itself (it does not workout).

By running the tests on a build server it will be able to spread the load of tests over several computers. This allows for much faster results, and build servers allow for adding compute nodes if the current amount is not enough. If we approach those 100 tests again but we distribute them over 10 computers, we will have our results of all the tests in a mere 20 minutes.

4. Free your computer

There are many different types of tests. Many of the UI testing tools do a decent job at not letting other actions on the computer affect the test, but they cannot completely isolate. Something as simple as moving your mouse over a browser, or scrolling on a different part of the screen could affect the test and cause it to fail. Many people simply do not touch their computer while the test is running to prevent any false failures. Wouldn’t it be great if you could run a test without it locking up your computer?

Tests running on the cloud have their own dedicated machine. You can run tests all day long and it will never slow you down.

5. Continue to build the automation project

When you run the test locally on your own machine, you have to have the current code on your machine ready to run. This means if you are working on the project, you may have the code in a non-runnable state when tests need to be ran, causing you to revert some of your changes or make a way around what you are working on till you have finished running the tests.

The build server will pull the code from wherever it is being saved, not your local machine. You can do anything you want with the code locally and it will not affect the test runs till you are ready to push the updates to where the server is getting code.

Bottom line: to make your tests more effective, use the cloud.

Git is version control. Meaning a way to track changes that happen in a project (directory of files) and save them as versions of the project.

How Does “git” Work

When a git project is initialized in a directory it creates what is called a repository, or a database to store the project. There are 3 steps to adding something to your git repository.

1. Make changes. Git does not lock your files so you are free to make any changes and the git repository will ignore these changes, or not track them, till you add them.
2. Add changed files. Adding the files you have changed still does not add those changes to the repository but rather tells Git to add these changed files to the next save you make.
3. Commit changed files. This will take all the changed files that have been added and save them to your repository as a new version.

This is a great way to save code projects because if something breaks you can go back and look at previous versions to find the change that caused the problem. Git also has branching that allows you to make changes to the repository on a branch and those changes will not affect other branches unless you merge the branches.

This repository is stored locally on the computer it is setup on, meaning if you want to collaborate with multiple people on a project or want to have a backup in case your computer crashes, you will need a central server to track your repository.

Git remote is a way to connect to a server that allows you to upload or download changes to the project using push and pull commands. There are services available to do this for you like GitHub or Bitbucket that have free plans for basic repository use. These services allow for collaboration and create the backup for the repository.

Basic Git Commands to get started

These commands are assuming you have git installed and you are at the top level directory of your project.

git config –global user.name “John Doe”
git config –global user.email johndoe@example.com

Sets the name and email for all commits made from that machine. Shen tracking changes this makes it is easy to see who made each change.

git init

Creates an empty git repository at the current directory.

git status

Outputs the status of your repository, including files you have added to be committed, files that have not been added, and which branch you are on.

git add src/file.java

Adds the file and its current changes to be saved on the next commit, additional usage for this command.

git add src/

Adds all the files that have been changed within the src directory.

git add -A

Adds all the files within the git project that have been changed.

git commit -m”my commit message”

Saves all the changes that were added. This saves to the git repository on your machine. Every commit must have a message associated to it, by doing -m allows you to add that message.

git clone https://git.repository.com/mygit/repo

Create a new directory called repo, make the directory a git repository and copy all the files from the git repository from the url.

git pull

Pulls the changes from your remote repository down to your local repository.

git push

Push the changes from your local repository up to your remote repository.

Why Do I Care?

Test automation is not like a normal development project. The goal is to get the result of a test to determine if your product is working. Thus you may not care about versions or tracking each change. There are also many automation teams consisting of one person to write the tests, no need for collaboration support.

There is the issue of backing up your code. Although there is plenty of solutions to backup files git does have a built in solution. If you accidentally delete the contents of an entire file, save the changes, and send it to your backup drive. The contents of that file can never be found again. Git keeps a history of all commits or versions ever made on the project. If the contents were deleted and it was not discovered that the deletion was made till a week later, you can still go through all the commits for the last week to find a version of the file before it was deleted.

As the project gets bigger there will be people who are interested how it is working, or offer to add some code to support something like a database connection. Without git you begin a mess of copying files and emailing them back and forth. Email is not a good way to handle files, there will be changes that will get lost. When your tests become so amazing that they add another person to the automation team, email will not be an option.When you have more than 15 or 20 (UI, selenium) tests you will find that they take a long time to run; wishing they would run on a different computer instead of your own. There are solutions that allow for running your tests on the cloud using build servers but they will need access to the code to run the tests. Using git remote in conjunction with GitHub or Bitbucket, while providing a great solution for backups, is an excellent way for the build server to access the code.