By Hayden Steel and Brodie O'Carroll 21 May 2020 Codebots Basics
No software should be released without adequate testing! In this article we cover the the `Test` section in the platform.
The Test section allows you to create and manage the tests which are run against your application. Using our tool, you can create human-readable tests with ease, giving you the peace of mind that your application is tested, but without the complexity of having to manually code the test.
The Codebots testing section is used to build tests for your application through an intuitive drag and drop interface. The interface is based on Scratch; a programming language used to teach children how to code. Think of it like Lego, where you order blocks to construct what you want. By using this approach writing tests becomes more meaningful, as they can be shared and understood across your cross functional team.
We categorise our tests into three different types:
- Platform written tests
- Bot written tests
- Developer written tests
The tests we cover in this article are the platform written tests. these are the types of tests you can build in the Codebots testing section of the platform. The bot written tests are just that, tests written by the bots to ensure that their own code is tested. The developer written tests are tests added by the developers directly into the source code. These tests are generally used to test custom code that has been added to the repository.
- Simple drag and drop interface that can be used to create user interface tests
- Ability to run these tests from inside the platform and see the results
- Ability to link the test up to the issues created in the Plan section and view the Traceability Matrix to see the connections between tests and issues.
How to use Test
The scenario builder is a tool to assist developers and non-developers to create simple browser tests for an application. The scenario builder is accessed by creating or editing a scenario. It contains a menu of
blocks on the left hand side and a canvas to hold your test on the right. Simply drag blocks from the menu onto the canvas to configure your test.
The tests are created in a popular Behaviour Driven Development (BDD) format known as
cucumber. As such the core block needed in your test is the
Scenario block, which contain the following spaces:
Given- Contains logic for setting up the test,
When- The core actions of the test, and
Then- The parts of you test for verifying that the action worked as intended.
A high level example in the case a test was being written to test we could login to our application might be:
- Given I navigate to my site
- When I type my credentials and hit login
- Then I expect to see my dashboard
In the scenario builder this would be achieved by using the other available
blocks to fill out the sections above. The other blocks are organised into the following main categories:
Page Actions- Blocks for navigating to URLs and refreshing the page
Interactive Actions- Blocks for clicking, typing, selecting things on the page
Waiting- Waiting for certain elements to be present, visible or for elements to be hidden or removed
Expect- Making assertions about elements, such as if a certain element is visible or has certain text
Path Selectors- Used to identify a certain element on the page , e.g. the login button or the page title
There are two blocks available in the Path Selectors category,
XPath of [blank] and
CSS of [blank]. As mentioned above the aim of these blocks is to identify a certain element on the page. The values put in these blocks can be found by inspecting the elements using a browser. The following are the simplest steps for getting these values from a element in Google Chrome:
- Right click on the element you wish to identify, e.g. the login button, and click inspect,
- This will open the Chrome Developer Tools and highlight the element you right clicked on,
- Right click on the highlighted element in the Chrome Developer Tools panel, and
- In the pop up menu select Copy -> XPath or Copy-> Selector to get the XPath or CSS Selector respectively.
These values can then be put into the free text part of the
XPath of [blank] blocks. It is worth noting that while this is the simplest method, these XPath's can sometimes be fragile and overcomplicated and sometimes other methods of obtaining an appropriate XPath be used.
Putting it together
To create a login test, like we described earlier, we need to make use of a combination of the above concepts. Below is a screen shot outlining how this might look.
Once a scenario is configured simply click run on the relevant tests to execute them. There will be a short delay while the test is queued before it moves to the running state. At this point the following will happen:
- Codebots will write the scenarios as cucumber files inside your application repository, commit and push them
- Codebots will spawn up your application in a sandboxed environment
- Codebots will execute the tests against this sandboxes environemnt and return the results
Linking tests to issues
The final part of the testing section is to associate tests to issues. This can be done from within the create/edit view of a Scenario. Simply type in the issue code or the summary into the search box under the Scenario name and select the appropriate issues. Once there are tests linked to issues you can use the
Tracebility tab to gain an insight into what issues are tested and which ones aren't.