Editors Note: You can read part one on the Acumatica SDK here. Also, Patrick did a session at our last Virtual Developer Conference this past June. You can find his session video, slides, and sample code along with a couple related sessions here.
One of the great and lesser known products that Acumatica ships with the ERP is the TEST SDK. For those of you who haven’t checked it out, the SDK is a Selenium based Test Automation Kit. The SDK is a “programming framework” that pINrovides an easy way to develop automated tests for applications built on top of the Acumatica Framework”. That quote comes from the included SDK – README doc that serves as a reference for the kit. Modern versions of this doc make it seem like this will become course material for certification purposes. If you haven’t, I recommend looking through the documentation, creating a test instance, and following the lessons to create your own Automation kit. In very basic terms, the kit will allow you to create a software package that will run through a list of instructions which will manipulate the UI as if there was a person on the mouse and keyboard. This is a great resource in terms of automating repetitive tasks, but at first can seem a bit limited. In this entry and subsequent entries, I’ll share some tips and tricks on how to get the most out of the SDK.
Work directly with SQL Server
One of the limitations of a UI testing platform is that it is designed to simulate a test by a non-technical user. It is great that you can program the system to open pages and point and click on the screen. But who is responsible for setting up the environment to start the test? In my personal testing practice, I like to perform tests on fresh installs of Acumatica so that no previously installed program elements are present when I evaluate software as part of my Alpha testing. However, there are a lot of other scenarios where this might be useful. You could also set it to restore a customer’s database – a database with lots of specific accounts or inventory or any other starting point for testing, depending on what you’re doing. The point is to have a discrete starting point so that bugs and anomalies show up readily in repeated testing.
Luckily the Acumatica Test SDK as a platform has plenty of native capabilities to talk to other systems. In this blog post, I’ll provide a code snippet that you can use to perform a MS SQL Server restore before you start each test. In the code below, you’ll see that I have a ‘Database Operations’ module that handles building a SQL command that is passed to a MS SQL Server that I’ve stipulated in my config file (see Part I of this Blog post). A connection is created with a .NET DataProvider and the command is passed.
The TestCombined object below comprises the main test file. For this simple test, I retrieve all the inputs (see Part I) and reset Acumatica to a fresh install. In a real test, I would add calls to more modules to do actual testing.
The ModRestoreDB module accomplishes the task of getting a fresh install of Acumatica ready for installation of whatever customization we’re testing. This involves unpublishing all customizations currently on the site, restoring a MSSQL backup, and finally logging back into the Acumatica instance.
The DatabaseOperations module contains functions pertaining to the SQL Server. In the example below, it only contains code for restoring the MSSQL server. This code was cobbled together from examples found on the internet, it consists of creating a custom SQL command based on your database info and executing that command.
I hope you’ve found these blog posts helpful and they’ve inspired you to add the Acumatica Test SDK into your development practices.