Monday, December 24, 2012

Enter The main(String[ ] args)



In the movie “The Matrix,” Morpheus attempts to describe and show to Neo what the matrix is by first loading them into the construct program.  There, can they load their look, equipment, guns or whatever they will require before going into The Matrix.  To me the use of “main” has a very similar functionality.  For the TestFramework, it can serve as both an entry point and a construct to the testrun.  This is the beginning to advancing your automated tests from simple function defined testcases to an actual TestFramework with both reusable and sophisticated functionality.

One definition of “main” is “the chief part, essential point.”  In the development world, main is often used as the default starting point of an application or program.  As test automation specialists, regardless if we are using an open source or commercial automated test tool, this is a good developer’s technique we can borrow for our automated efforts especially if we are learning to mature our efforts beyond glorified record and playback.

Anatomy of Main

I see main having three parts:
  • Function/method defined as main which serves as the entry point to your TestFramework
  • String based array/argument list which transports parameters into your TestFramework
  • A set of code or function calls designed to construct your testrun.
We should strive to keep main this simple and leverage development techniques of object oriented programming to optimally build the functionality we desire in our TestFramework.  By the way, this concept is supported by whatever your desired programming language is.  Mine is java, what is yours?

Growing Up From the Play Button

In the elementary school of test automation, we basically learn to create a test scenario by coding testcases as functions within a script.  When we are done, we click “Play.”  As we continue our automation efforts, we create more and more of these test scripts and when we want to run them, we simply select one and click “Play.”  Even if we are using an IDE to work with our open source tool, we still manage to click the play button to run our scripts.  As we are matriculating our way to advancing our test automation approaches, we can leverage main as a way to auto-select the test scripts and/or test case functions we desire to execute for the given testrun. This will then mature your automation to efficiently construct the testrun and provide flexibility of starting your testruns from batch command files, from schedulers or even as part of your build process.  Think about it!  You can automate even the way you start your automation efforts!


One component of my TestFramework that I can share with you is the TestDriver program which begins with main(Strings[] args).  The TestDriver serves as both my “entry point” into the TestFramework and a way to construct my current testrun.   Some people may also refer to this as a TestLaunch program.
One thing I will confess to is, I no longer pass arguments to main to configure my testrun.  In the beginning I did.  I used a configuration tool I built using Excel to guide me through configuring a testrun and then the settings were saved to a properties file.  Sometimes I had multiple property files simply so I didn’t have to recreate settings.  So then I would pass the name of the file to main.  However now, my preference is to use either a test management or application life cycle tool where the testrun parameters are set by a testset.  The information is collected by the TestFramework’s service layer.  That is another topic for another day.

TestDriver EntryPoint

When an automated testrun begins, the TestDriver is the program I call usually from a batch command.  When I am using an open source tool like Selenium, I might call it like, testdriver config.prop if I was still using a properties file.  The config.prop file contains a number of properties I want to use to construct my testrun.  Often, I can make this call from:
  • a scheduling program, or
  • a listening program designed to run the test at a specific time, or
  • when it detects a new build is ready for testing.
Most commercial based testing tools also support starting from the command line so you also can take advantage of the flexibility to auto-start your tests.

TestDriver Construct

Once I have begun my test, I can elect to construct the testrun prior to executing the testcases.  Constructing the testrun adds a tremendous amount of flexibility to the TestFramework and promotes code reusability.  Using the example below, one could:

public static void main(String[] args) {

Integer i = 0;
//In this example, we pass the testsets we wish to test and we have the flexibility to test one, many or all testsets.
for (String testSetName : args) {

System.out.println("NOW TESTING:  " + testSetName);            System.out.println("=======================================================");
if (p.getProperty(testSetName).equals("Yes")) {

// Verify the application is ready for testing, i.e the new build has finished successfully.

//Use the build name to dynamically define a release for the current testset being processed.
defineReleaseIds (testSetName);

// Login to the web service client of the TestManagement system.

// Take the dynamically built release name and create a version in the TestManagement system.

// Get the auto-generated id from the newly created version and set it as a global variable for the TestFramework.

//Get the auto-generated id from the testset name and set it as a global variable for the TestFramework.

// Use the testset global variable id and update the current testset with the version and release id currently under test.

//Create a new testrun from this testset in the TestManagement system.

// Download the testcases from the testset and the testcase’s testrun ids to the TestFramework and set the information to a collection.

// Add the testcases from the newly created testrun to the release

// Process each testcase in the testset and if the testcase fails, collect supporting information and update the testcase in the collection.

// On completion of processing the testcases, update the testset with the lastest results.

//Upload the modified collection of testcases to the TestManagement system which will also upload to the testcase steps the actual results, application logs and screen shots if the test case did not pass.

// This method was called by the updateTestManageTestcases function when it encountered a failed testcase.  It should create the defect, link to the testcase, capture the teststeps, and capture the supporting information and save to the TestManagement’s defect tracking system.
createDefectReport (testSetName);

//On testrun complete, logoff from the TestManagement system’s web client.
disconnectFromTestManagement ();


// After the test run, this method would send two types of emails.  One to the tester providing a summary of the test results and where they can locate them in the TestManagement system and an email to each system owner if there was a problem detected with their respective system.

// This method would create two types of graphs.  A bar chart providing the test statuses for each testset (i.e. test environment) and a fail report notifying system owners of machine, network or application failures.  Both reports showed on a large viewing monitor.

This is only one example of using main to both to begin and construct a testrun.  Of course you will have your own ideas on what to construct and what to manage.  I hope so!  Have fun with it.


So you see main(String[] args) can be our friend too.  It can help us as little or as much as we require it too.  Yeah I know there is a lot of work to build that kind of support but you can begin to evolve it over time.  Just pick a starting point that is most important to you.  Main will always be there to help you keep it organized and efficient.

Happy Automation!

No comments:

Post a Comment