Standard tests using Mocha
Before moving to the Model Based Testing approach Vitaq AI Test Automation. We first need to look at how we would use one of the conventional test frameworks such as Mocha.
When implementing what I would call the “traditional” (i.e. common sequential way) automated tests, we implement a set of sequential actions and one, or more, asserts/expectaction checks. In this case we normally hard-code the data although we can use the faker library to create more variable data. Although this is difficult to make reproducible because it is random.
Traditional, sequential tests can be easy to implement and read (its code). However, they can become harder and harder to manage the bigger the test space is. The really big limitation is that they will ONLY test the hard-coded paths which quite often are the happy paths.
Sequential vs Model Based Testing
With Vitaq AI we’re not focused on simple happy paths. Instead, we look at the test space from many different perspectives, like “all” possible ways of interacting with it. Therefore, QA coverage with Vitaq AI increases because many more paths are exercised. By using AI machine learning to walk though those paths, we can expose hidden risks that otherwise we would miss.
There are many conventional test environments like Mocha used widely today including Jasmine, Jest, and Espresso.
All of these approaches require the user to write many individual tests that are then tied together to execute test scenarios. The user focuses their test writing on a very directed user-journey and one-shot data used.
Running these tests typically takes minutes and to achieve high test coverage the user will need to write test after test after test. Using their intuition and knowledge of their app under test many weeks of test scripting and debugging will be undertaken.
There is a more efficient and effective way of achieving high test space coverage by using the power of variability and the compute of AI-Driven Vitaq Test Automation (https://vitaq.io/2020/11/01/why-vitaq-ai-and-why-now/) to reduce the amount of scriptwriting needed and maximize the continuous test execution of data-driven test scenarios to achieve much more testing with much less effort.
But before we introduce you to your new life as a Tester. Let’s briefly touch on what we do today with conventional test frameworks like Mocha.
Page Object Model (POM)
After Gathering Requirements we usually create a Test Environment. We have used Page-Object-Model for that. As we know page-object-model approach allows you to split your test logic from the UI representation.
As a result:-
1. You can develop your tests faster
2. You can re-use earlier created objects for one test in another test
3. If UI changes you don’t need to change your test logic, all you need to do is to amend the relevant Page Object(s) to reflect the changes – the test code remains the same
Following Page-Object-Model, we have also created a sort of framework for carrying out Test Activities on AutomationPractice.com
Here we have kept page objects for every page under the folder named as pages:-
Likewise, we have kept our test files under the Test Folder.
We of course have a config file that checks which test we need to run and on which browser.
This is the Conventional Approach we are following in our day to day Test Automation Task, writing test after test after test after test. Are you exhausted yet?