In order to get started the student is encouraged to create a Udemy project in the Boozang Cloud. This way the student can follow along all the lectures by creating their own automated tests. This requires the student to create a free account at https://boozang.com using their email address. The name for the project used in the course is "TheShop" but you can choose anything you like. The web application we will be testing is "http://theshop.boozang.com" and it needs to be entered on project creation.
Overview of the Boozang tool. The Boozang tool has a lot of features that we are not going into, so take your time to get familiar with the tool, especially the multi-level navigation which can be a little tricky at first.
Now you are ready to record your first test. This lecture outlines how you can record a simple test scenario using the Boozang tool.
Validations (a.k.a. assertions) are a core concept in test automation. Here we create a first simple "Validate Exists" condition. In Boozang a number of Validations are supported. For a deep-dive, consult the official documentation: http://docs.boozang.com/#validations.
The "Add to cart" test we created wasn't strict enough. We improve the element path by using the edit function in the "Element" tab. Element paths are a complicated topic in itself, and Boozang has invented its own policy. To get more information on this, check the official Boozang documentation: http://docs.boozang.com/#elements.
Test suites are used to setup a test execution sequence of other tests. As any test in Boozang can call other tests via the plug-test cation, test suites works just like other tests in Boozang.
After this lecture you will have created your data-driven test. Using data is central to Boozang and test-automation in general. In tests where the data is hard-coded, test are not re-usable, and the test stack would quickly grow to thousands of tests. This would be unfeasible in terms of management and maintenance.
Here we create a data-driven validation. If we create our "action-tests" to adapt to data, we also have to make our "validation" tests do the same.
In this tests, we add parameter data to the test suite, and show how we can send this downstream to the tests in question.
Setting up the initial testing conditions before running a test is crucial to avoiding getting unexpected failures. In our simple case, this simply means making sure the shopping cart is cleared. We customize action "exit conditions" to simply skip the test if the cart is already empty, instead of reporting a failure.
In this test, we loop over a list of product items to highlight the usefulness of data-driven tests. We use the array data "$test.items" and use the handle "$loop" to access the items ("$test.items[index]).
In this test we give a really quick introduction to Cucumber tests. The Cucumber features for TheShop can be found at https://github.com/ljunggren/theShop. To learn more about the Cucumber language, see the official Cucumber site: https://cucumber.io/ and the Boozang forum: https://cucumber.io/
We import the features from GitHub.
Running the clear cart test should only be needed when the cart is actually has contents. We utilize a validation condition to only clear the cart when it has contents.
This time we look at how we can validate the cart contents based on data. We see that the validation can happen on the page underneath the cart, so we look how we can make the element path more specific using the edit element function (DOM picker).
We also add a validation that takes "price" as a parameter, and validates the total price in the cart.
After learning to record simple navigation tests and being able to add things to the shopping cart, the natural next step is to checkout the goods. We here record a simple check-out. We use static data to fill out the payment form.
Here we again create a checkout, but we save the form information as Boozang data, so it can be changed independent of the test. We use the static data test as a starting point and replace it with Boozang data that we define on $module level.
Instead of starting with a recorded test case with static data, we use data bind functionality to directly use the data we have defined at $module level to bind it into the payment for as we record the test.
In this example, we replace some of the data with random data generated from regular expressions.
Here, we look at the Checkout scenario in Cucumber and bind it to the tests in the previous scenario.
We do the same for approve order, but run into trouble when trying to validate that the order was done. We add a TODO marker to the test to remind us we need to go back and fix at a later point in time.