Package Development: Writing a Test Class

  • 23 February 2021
  • 0 replies
  • 118 views

Userlevel 7
Badge +10

 

 

In a previous post on package development, we took a look at returning a Dictionary as a part of the package's action. In this post, we'll take a look at the breakdown of a test class from that same project - which allows developers to simulate the process of a user mapping data to fields in the Control Room UI, and see the resulting data from the Java IDE before going through the build/install process that would otherwise be required.

 

To be very clear - the use of a test class is one way to validate the functionality of a custom package, but in and of itself is not the full extent of testing that should be performed. While a test class can be great for validating basic functionality, it's still important for developers to test their custom package with an actual bot to validate that field labels, descriptions, icons, etc. show up as expected - and that the actions of the package work as they should.

 

If you want to download the sample code and follow along with the rest of this blog post, you can find the code on the Automation Anywhere GitHub page. The screenshots and testing for this blog post was done using IntelliJ IDEA Community Edition 2020.3.2 (free) - if you're using a different IDE or different version of Community Edition, expect that some functionality and visuals may look slightly different than what you see. Taking a step back as a quick refresher, the package we're dealing with simply takes in a String value and a Number value - returning both of those values in the form of a Dictionary that can be used by a bot. The package itself only has a single action - ValuesToDictionary - which defines the mentioned input parameters and return data type.

 

ValuesToDictionaryTest Class

 

In an effort to test the functionality of the ValuesToDictionary class before compiling, installing to the CR, and creating/running a bot - a test class is created which will enable us to simulate how the Values to Dictionary action will operate. Inside the class definition, the Test annotation is used to identify the testValuesToDictionary function as a test. Inside the testValuestoDictionary function, String and Double values (expectedString and expectedNumber respectively) are established and given default values to use as a test. The values are then added to a Map called expectedDictionary.

 

String expectedString = "Go be Great!";
Double expectedNumber = 100.0;

 

A ValuesToDictionary object named testPackage is created and a DictionaryValue (com.automationanywhere.botcommand.data.iml) named packageOutput is established and assigned to the output of the testPackage.action (which invokes the action created in the ValuesToDictionary class).

 

//new ValuesToDictionary Object for testing
ValuesToDictionary testPackage = new ValuesToDictionary();
//Assigning output from the ValuesToDictionaryAction to a Dictionary
DictionaryValue packageOutput = testPackage.action(expectedString, expectedNumber);

 

By this point, the package output DictionaryValue should be returned with the dictionary created in the ValuesToDictionaryClass. To validate that (and execute the test) - 2 print statements are used to see the contents of the first value provided vs the FirstValue coming from the returned dictionary (they should obviously match). Finally, the Assert.assertEquals statements are used to execute the actual test on both of the input values to ensure they match.

 

//Write out to see results
System.out.println("First Value: " + packageOutput.get("FirstValue").toString());
System.out.println("Expected First Value: " + expectedString);
Assert.assertEquals(packageOutput.get("FirstValue").toString(), expectedString);
Assert.assertEquals(packageOutput.get("SecondValue").getAsDouble(), expectedNumber);

 

The whole purpose of this test class is to validate how the action would behave given the provided parameters that that would otherwise be filled in by a bot builder when using this package from the Control Room UI. You should be able to execute the test case in IntelliJ by clicking the "Run" icon next to the ValuesToDictionaryTest class definition.

 

 

(If you're not seeing that as an available option, go to File > Settings to bring up the settings screen. Navigate to Build, Execution, Deployment > Build Tools > Gradle and select the option to "Run tests using: IntelliJ IDEA" and hit Apply/OK.) The result of executing the test should be displayed in the console with FirstValue and Expected First value both printed out along with the Default Suite indicating the number of executed and successful tests. Note: The test is also executed as a part of the build process - so if your test case isn't working, you'll need to resolve that before building the solution and testing in the Control Room.

 

First Value: Go be Great!
Expected First Value: Go be Great!

===============================================
Default Suite
Total tests run: 1, Failures: 0, Skips: 0
===============================================


Process finished with exit code 0

 

Building the Project (Optional)

 

If you want to actually compile the package for testing in your Control Room, click to open the Gradle tab on the far right side of your screen (if it's not showing up, navigate to Window > Restore Default Layout). Once there, click the Execute Gradle Task button (the elephant).

 

 

From there, the Run Anything window appears and enables you to build the project by typing clean build shadowJar. Once executed, the project will build in the Run interface at the bottom of the screen and the package jar file will be generated in the /build/libs directory of your project.

 

 

Alternatively, you could navigate to the project root directory using Bash Shell/PowerShell and execute the following command:

.gradlew.bat clean build shadowJar

 

Conclusion

 

The customizable nature of Enterprise A2019 enables developers to create and share custom packages that can enable more advanced bot builds at an accelerated rate of development. While testing in the Enterprise A2019 Control Room interface is critical to validate the full functionality and design of a custom package, testing in a Java IDE enables developers to validate the core logic of their package before going through the process of installing and creating a bot. Go build (and test) better bots, and Go Be Great! For more on package development, see the full tutorial on How to Build a Twilio Package using the Enterprise A2019 Package SDK.


0 replies

Be the first to reply!

Reply