Workshop (Test engineering)
The assumption is you have set up accounts on Github - you can use you GitHub credentials to login to both Travis-CI and Netlify when the time comes.
While it will be important to understand running commands from a Terminal, for this training guide, using the web services will be sufficient.
GitHub is a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere.
Github is a service where you can keep your code, and make it available to others. After setting up your account, click the ”+” symbol in the top-right of the menu bar.
The defaults are ok, but remember to select to add README to add repo info.
After creating repo, click “Create New File” and enter filename
Now we can start the coding!
Scroll down to see lines of code highlighted, alongside explanations.
DOCTYPE tells the web browser about what version of HTML the page is written in (in this case HTML5)
The html element tag is called the root element because it contains all the elements in the document
The head element tag contains descriptive information about the document itself, such as its title
The body element tag contains everything that we want to show up in the browser window.
Simple form example
A text field definition for our search
Add a button element with label text, to submit the form.
A basic text hyperlink.
Insert an image, “src” value is the path to image file.
The closing tag for “body”.
The closing tag for
Now we have a basic web page to test on!
On software development projects, testing work is driven by what the client has asked for.
This is a continual process that never stops, and it’s important the tests reflect this.
However this not not mean testers do not manually test - on the contrary, due to the nature of UI test automation, work is constantly validated.
In further training I will go into the other sides of test automation (such as load and security testing) in future training guides.
But also it’s important to remember to think creatively, and develop other useful tests (this is where developers can help you out, and will be more than happy to!).
What many testers forget, is that most developers welcome dialogue with testers, as they know how helpful they can be.
For convenience to install packages, it is better to create a file
package.jsonin the root of your repo, like shown here, then run
Create a new file in ‘tests’ folder called
test.js. When this code is run, it first fires up Chromes browser, then excecutes the actions in the script.
Although the purpose of tests varies, the context is similar:
- I do something
- Something happens
So test steps are (simplified) an action followed by consequence(s) - the consequence is how we verify is a test has passed or failed.
Now lets look at the lines of code in more detail …
The easiest way to look at this, is it’s creating an object that’s webdriver. Chrome will run the automated tests without UI (good for speed).
headlessmeans no browser will be visible on screen.
disable-gpumeans disable graphics acceleration for Chrome.
This is creating an object that is the browser.
This is the script, the first line opens up the url, the next lines locate an element and perform an action.
Close browser session.
$ cd /path/to/your/test$ node test.js
At this point we have been working on the default
master branch, but in order to make sure we have a stable pipeline it is better to do work and test on a separate branch.
So now create a branch called
travis-ci, which will be used by Travis CI
- Go to your new repository
- Click the drop down at the top of the file list that says branch: master.
- Type a branch name, readme-edits, into the new branch text box.
- Select the blue Create branch box or hit “Enter” on your keyboard.
A build server (also called a continuous integration server (CI server)), is a centralized, stable and reliable environment for building software.
Developers on projects use the build server all the time, as it’s the place that their code is built and tested.
Now we have the code, we need the run the tests each time the code changes, to make sure our changes don’t break it.
The tests we currently start manually, but using a build server service, like Travis, these can be run automatically every time you change your code.
Basically all we have to do, is take the exact steps you did in the previous section, and put them into the simple build configuration file format.
Create a new file in your repo folder named
Add the code
We need to write small configuration file, so that when Travis pulls the code from your GitHub repo, it knows what to do.
The file is very simple for us, so create new file in your repo called
After these steps are all in your code, and committed, a build process will automatically start on TravisCI
After build has completed. it will either Pass for Fail
Go to your dashboard and search for your repo
Then move switch on right so it turns green - your repo will now run through and build and test every time you change your code on GitHub.
Add the following code to your README, and it will display the lastest Travis status for your code:
Now we know out build works on the build server, it’s time to deploy to Netlify, using our
master, so now we need to do a Pull Request from the
travis-ci branch, which when merged will trigger a deploy to Netlify (we are now going to set that up).
Strictly this would not be a deployment to live website (which I am doing here for simplicity), it would be a deployment to a test website so we can check things visually before manually deploying to live website.
Now log into https://app.netlify.com (you can use your GitHub account to do this)
Click the “New site from Git” button, then click “GutHub” button (which will create connection between netlify and GitHub)
Type in your repo name into search, then click on the repo link
Leave defaults, and click “Deploy site”
The output from the Netlify process to make your site live
After completing this course, you should have the following files in the root of your repo folder: