Recently in Raves Category

.....::::: UPDATE :::::.....

Cedric Beust (the guy who wrote the book on TestNG) added a comment with a way to run single tests much much easier.  Go check out the comment below.  I'm going to leave this article up, though, I think that people might find the examples of parameters and groups might still prove useful.

----------------------------------

It's a typical story.  You have all of your tests written up with Selenium and everything is working beautifully.  Then you discover the beauty of TestNG's ability to run the tests in parallel. By adding some parameters to the XML, you are able to run multiple copies of the same tests on different browsers and operating systems. The clouds part, the angels sing on high, and you find your boss showering you with praise for cutting the total run time from four hours down to fifteen minutes.

But all is not as good as you thought.  Those blasted developers decided to change something on the page and one of your two hundred thirty-four tests is now broken. So, you dutifully open Eclipse and begin the repair work.  You finish adjusting your assertions, right-click on your test method and choose to "run as TestNG test."

Despair!  Anguish!! Gnashing of teeth!!! I don't want to run my entire class of tests just to debug a single test!!

"What the hell does that mean?"  you ask as you stare at the console output, which tells you ...

 

org.testng.TestNGException:
Parameter 'browser' is required by @Configuration on method setUp
but has not been marked @Optional or defined in C:\<MyUserDir>\AppData\Local\Temp\testng-eclipse--1466657283\testng-customsuite.xml
    at org.testng.internal.Parameters.createParameters(Parameters.java:144)
    at org.testng.internal.Parameters.createParameters(Parameters.java:327) ...

 

Apparently, when you attempt to run a single test, you are never asked to point Eclipse at the XML file you wanted to use.  Eclipse and TestNG create a nice temporary one just for the occasion.  Unfortunately, there is no way to tell the IDE where to get any XML information from.

After much cursing, scouring Google, and complaining to my co-workers, I have devised a method that allows me to run any single test (or combination of tests) without having to run the entire class' list of tests.

Here's how ...

Create an XML file for your own debugging purposes. 
You probably want to use all of your typical parameters like browser type, location of the Selenium Server/Grid Hub that you want to use, etc.

   1:  <!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
   2:   
   3:  <suite name="MyTests" verbose="-1" parallel="tests" thread-count="1">
   4:        
   5:        <parameter name="seleniumGridIp" value="localhost"/>
   6:        <parameter name="seleniumGridPort" value="4444"/>
   7:        <parameter name="testServer" value="http://myServer.domain.com:8080"/>
   8:        <parameter name="debugLevel" value="1"/>
   9:        <parameter name="dbEnvironment" value="dev"/>
  10:        <parameter name="testInfoSaveLocation" value="test-output/" />
  11:        
  12:        <test name="Edit Page Tests" preserve-order="true">
  13:             <parameter name="browser" value="*firefox"/>
  14:             <classes>
  15:                  <class name="com.packageName.BusinessListingPageTests"/>
  16:             </classes>          
  17:             <groups>
  18:                  <run>
  19:                      <include name="single" />
  20:                 </run>
  21:             </groups>        
  22:       </test> 
  23:  </suite>

 

The key to successfully running tests individually lies in lines 17 - 21.  By using groups, you can have your XML test suite run only those tests that you want to run.

The next step requires a few edits to your test classes themselves.  I'm using JAVA in these examples, but I'm sure that the principle relates to other languages as well.

For EVERYTHING you wish to have run along with your tests ( perhaps you have some database setup you want to do) , you must tell the Eclipse/TestNG unholy alliance that you want it to run.  This is simply accomplished by using TestNG annotations, as follows...

 

   1:  @BeforeClass( groups = {"single"} )
   2:  @Parameters({"browser", "seleniumGridIp", "seleniumGridPort", "testServer" })
   3:  public void setUp( String browser, String seleniumGridIp,
   4:       int seleniumGridPort, String testServer) throws Exception {
   5:   
   6:       Selenium sel = new DefaultSelenium( seleniumGridIp, seleniumGridPort,                                                                                                browser,     testServer);
   7:          
   8:       sel.start();
   9:       sel.open(testServer + LoginPage.PAGE_NAME);
  10:       sel.waitForPageToLoad("10000");
  11:  }
  12:   
  13:  @Test( dataProvider = "userSetup", groups = {"single"})
  14:  public void testChangeHoursOfOperation( String userName, String password,String businessId){
  15:       User user = new User();
  16:       user.userName = userName;
  17:       user.password = password;
  18:   
  19:       LoginPage login = new LoginPage(sel);
  20:       login.LISTING_ID = businessId;
  21:       login.setBrowserToStartPage();
  22:       login.loginUserName(user);
  23:   
  24:       assertTrue(amIOnTheStartPage());
  25:  }
  26:   
  27:  @AfterClass(groups = {"single"})
  28:  public void tearDown() throws Exception {
  29:       sel.stop();
  30:  }

 

That's it.  When you run the XML, now your single test will run all by it's lonesome.  When you don't want to run that single test anymore, simply remove the group from the @BeforeClass annotation.  It is very important, though, that you remember to include the group in the annotations for the setUp() and tearDown() methods, or they won't be run.  Its kinda hard to run a Selenium test if the IDE doesn't know where to find the Selenium Server.

 

I hope this helps someone.  If you have any questions, or feedback, please feel free to drop me an email and I'll be happy to clarify any point.

 

You’ll Be Amazed

| | TrackBacks (0)

We all hear about the Hubble Telescope.  Many of us will remember the snafu upon its launch.  The main mirror had been ground incorrectly and we weren't FileHST-SM4 able to fully utilize it until the first service mission in 1993.  But ever since then, the Hubble Space Telescope has been raining down data like digital manna from heaven.  I think we've become jaded to the wonder of it.  We've grown complacent with its abilities. 

Well, I'm here to bring your attention to this wonderful piece of technology.  Go take a look at some of its beautiful photos in the gallery.  I promise you, you'll be amazed at the stunning beauty that makes up our night time sky.

One mind blowing thing about this:  We are actually looking back in time whenever we look at stars and galaxies.  The closest star to us is 4.37 light years away from us.  That means, when we look at see that star system through a telescope, we are seeing the light that left the binary star system 4.37 years ago.  We are, in effect, looking 4.37 years into the past.  Now take that thought and apply it some of the most distant galaxies that the Hubble is able to peer at.  Billions of light years away...  We are literally looking at images of the universe from billions of years ago.  Creeping our perception ever closer to the beginning of it all.  That's about 700 million years since the Big Bang, or almost 95% of the way back to the beginning. Staggering to think about.  Read from the related articles below to learn more about this.

 

 

 

 

 

The Tao of Calvin