Looks like your config-file parameter is not defined at the <suite> level. There are several ways to solve this: 1. Make sure the <parameter> element is defined within <suite> tag but outside of any <test>:

 <suite name="Suite1" >
   <parameter name="config-file" value="src/test/resources/config.properties/" />
   <test name="Test1" >
      <!-- not here -->
   </test>
 </suite>

2. If you want to have the default value for the parameter in the Java code despite the fact it is specified in testng.xml or not, you can add @Optional annotation to the method parameter:

@BeforeSuite
@Parameters( {"config-file"} )
public void initFramework(@Optional("src/test/resources/config.properties/") String configfile) {
    //method implementation here
}

EDIT (based on posted testng.xml):

Option 1:

<suite>
  <parameter name="config-file" value="src/test/resources/config.properties/"/>
  <test >
    <groups>
      <run>
        <include name="abstract"/>
        <include name="Sanity"/>
      </run>
    </groups>
    <classes>
      <!--put classes here -->
    </classes>
  </test> 
</suite>

Option 2:

@BeforeTest
@Parameters( {"config-file"} )
public void initFramework(@Optional("src/test/resources/config.properties/") String configfile) {
    //method implementation here
}

In any case, I would recommend not having two parameters with almost identical names, identical values, and different scope.

If you have a google drive or dropbox accounts, you probably have "dropbox" or "doogle drive" applications installed. Those applications sync contents of your local folders with the cloud. Simply save your screenshots in that folder and you're good to go. Google Drive app Dropbox app

If you experience problem with saving the screenshot itself, please provide the error message you get, or at least a screenshot. I'll be glad to help.

Possible Solution 1: Execute javascript call to sendKeys() As you stated, it is most likely the formatting of the textbox that is not allowing you to sendKeys() to the input box. The reason might just be the way that WebDriver handles putting input into a box. I'd recommend trying javascript to execute a different type of input filling method.

WebDriver driver = new FirefoxDriver();

JavascriptExecutor executor = (JavascriptExecutor)driver;

executor.executeScript("document.getElementById("SSN").value='55555';);

Possible Solution 2: https://github.com/dsheiko/autofill

I don't have a good code snippet that i can show you for utilizing autofill, but the github itself has pretty nice examples.

Possible Solution 3: Remove the formatting attribute of the input tag, then use sendKeys()

((JavascriptExecutor) driver).executeScript("document.getElementsByID('SSN'[0].removeAttribute('data-val-regex-pattern');");
    WebElement input= driver.findElement(By.id("SSN"));
    input.clear();
    input.sendKeys("55555");

OK, I think this is very specific to TestNG configurations, since all of the JUnit examples work 'out of the box'!

Read through this link from the PowerMock GitHub site which describes further detail on how to use TestNG together with PowerMock. Exactly your scenario of verifying calls to mocked static methods is described there using this example code:

@PrepareForTest(IdGenerator.class)
public class MyTestClass {

   @Test
   public void demoStaticMethodMocking() throws Exception {
      mockStatic(IdGenerator.class);
      when(IdGenerator.generateNewId()).thenReturn(2L);       
      new ClassUnderTest().methodToTest();

      // Optionally verify that the static method was actually called
      verifyStatic();
      IdGenerator.generateNewId();
   }

}

Which is then followed by this nugget of information:

For this to work you need to tell TestNG to use the PowerMock object factory

This is done using either TestNG XML config, or in the test's code itself. For completeness I've copied below the options given at the above URL. FWIW I extended PowerMockTestCase and the verification worked as you expect.

Finally, don't forget to @PrepareForTest the correct class - i.e. the class containing the static methods which you want to mock, as @Bax pointed out here.

As a further hint (which you probably already know about, but worth mentioning here anyway) since you aren't using Mockito to mock objects, MockitoAnnotations.initMocks(this) can be safely deleted.

Once you've got all this working, you might also like to consider whether the use of 'Black Magic' tools like Powermock is actually exposing code smells in your design? Especially since it looks like the classes containing static methods are under your ownership. This means you could use an alternative design that doesn't use statics. I highly recommend Michael Feathers' book Working Effectively with Legacy Code, it might just change your whole approach to software design and testing...

Good luck!

Configure TestNG to use the PowerMock object factory

Using suite.xml

In your suite.xml add the following in the suite tag: object-factory="org.powermock.modules.testng.PowerMockObjectFactory" e.g.

<suite name="dgf" verbose="10"
    object-factory="org.powermock.modules.testng.PowerMockObjectFactory">
    <test name="dgf">
        <classes>
            <class name="com.mycompany.Test1"/>
            <class name="com.mycompany.Test2"/>
        </classes>
    </test> 

If you're using Maven you may need to point out the file to Surefire:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <suiteXmlFiles>
        <suiteXmlFile>suite.xml</suiteXmlFile>
        </suiteXmlFiles>
    </configuration> 
</plugin> 

Programmatically

Add a method like this to your test class:

@ObjectFactory public IObjectFactory getObjectFactory() {
     return new org.powermock.modules.testng.PowerMockObjectFactory(); 
} 

or to be on the safe side you can also extend from the PowerMockTestCase:

@PrepareForTest(IdGenerator.class) 
public class MyTestClass extends PowerMockTestCase { ... }

See Update below: You don't need a Factory

If you are using Jersey 2, one solution would be to use Custom Injection and Lifecycle Management feature (with HK2 - which comes with the Jersey dist). Also required would be a Mocking framework of course. I'm going to use Mockito.

First create a Factory with mocked instance:

public static interface GreetingService {
    public String getGreeting(String name);
}

public static class MockGreetingServiceFactory 
                                     implements Factory<GreetingService> {
    @Override
    public GreetingService provide() {
        final GreetingService mockedService
                = Mockito.mock(GreetingService.class);
        Mockito.when(mockedService.getGreeting(Mockito.anyString()))
                .thenAnswer(new Answer<String>() {
                    @Override
                    public String answer(InvocationOnMock invocation) 
                                                      throws Throwable {
                        String name = (String)invocation.getArguments()[0];
                        return "Hello " + name;
                    }

                });
        return mockedService;
    }

    @Override
    public void dispose(GreetingService t) {}
}

Then use the AbstractBinder to bind the factory to the interface/service class, and register the binder. (It's all described in the link above):

@Override
public Application configure() {
    AbstractBinder binder = new AbstractBinder() {
        @Override
        protected void configure() {
            bindFactory(MockGreetingServiceFactory.class)
                               .to(GreetingService.class);
        }
    };
    ResourceConfig config = new ResourceConfig(GreetingResource.class);
    config.register(binder);
    return config;
}

Seems like a lot, but it's just an option. I'm not too familiar with the test framework, or if it has an mocking capabilities for injection.

Here is the full test:

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.QueryParam;
import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.core.Application;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
import org.glassfish.hk2.api.Factory;
import org.glassfish.hk2.utilities.binding.AbstractBinder;
import org.glassfish.jersey.server.ResourceConfig;
import org.glassfish.jersey.test.JerseyTest;
import org.junit.Assert;
import org.junit.Test;
import org.mockito.Mockito;
import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;

public class ServiceMockingTest extends JerseyTest {

    @Path("/greeting")
    public static class GreetingResource {

        @Inject
        private GreetingService greetingService;

        @GET
        @Produces(MediaType.TEXT_PLAIN)
        public String getGreeting(@QueryParam("name") String name) {
            return greetingService.getGreeting(name);
        }
    }

    public static interface GreetingService {
        public String getGreeting(String name);
    }
    
    public static class MockGreetingServiceFactory 
                                  implements Factory<GreetingService> {
        @Override
        public GreetingService provide() {
            final GreetingService mockedService
                    = Mockito.mock(GreetingService.class);
            Mockito.when(mockedService.getGreeting(Mockito.anyString()))
                    .thenAnswer(new Answer<String>() {
                        @Override
                        public String answer(InvocationOnMock invocation) 
                                                       throws Throwable {
                            String name = (String)invocation.getArguments()[0];
                            return "Hello " + name;
                        }

                    });
            return mockedService;
        }

        @Override
        public void dispose(GreetingService t) {}
    }

    @Override
    public Application configure() {
        AbstractBinder binder = new AbstractBinder() {
            @Override
            protected void configure() {
                bindFactory(MockGreetingServiceFactory.class)
                        .to(GreetingService.class);
            }
        };
        ResourceConfig config = new ResourceConfig(GreetingResource.class);
        config.register(binder);
        return config;
    }
    
    @Test
    public void testMockedGreetingService() {
        Client client = ClientBuilder.newClient();
        Response response = client.target("http://localhost:9998/greeting")
                .queryParam("name", "peeskillet")
                .request(MediaType.TEXT_PLAIN).get();
        Assert.assertEquals(200, response.getStatus());
        
        String msg = response.readEntity(String.class);
        Assert.assertEquals("Hello peeskillet", msg);
        System.out.println("Message: " + msg);
        
        response.close();
        client.close();
       
    }
}

Dependencies for this test:

<dependency>
    <groupId>org.glassfish.jersey.test-framework.providers</groupId>
    <artifactId>jersey-test-framework-provider-grizzly2</artifactId>
    <version>2.13</version>
</dependency>
<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-all</artifactId>
    <version>1.9.0</version>
</dependency>

UPDATE

So in most cases, you really don't need a Factory. You can simply bind the mock instance with its contract:

@Mock
private Service service;

@Override
public ResourceConfig configure() {
    MockitoAnnotations.initMocks(this);
    return new ResourceConfig()
        .register(MyResource.class)
        .register(new AbstractBinder() {
            @Override
            protected configure() {
                bind(service).to(Service.class);
            }
        });
}

@Test
public void test() {
    when(service.getSomething()).thenReturn("Something");
    // test
}

Much simpler!

This is a valid doubt many testers have. Because the main() method is needed to run the Java program and while writing tests in TestNg we don't use main() method, and we use Annotations instead.

Annotations in TestNG are lines of code that can control how the method below them will be executed. So, in short you don't need to write main() method, TestNg do that by itself. Refer the code at the end in Annotations documentation to get the idea how it happens.

As rightly pointed out in this answer: https://stackoverflow.com/a/1918154/3619412

Annotations are meta-meta-objects which can be used to describe other meta-objects. Meta-objects are classes, fields and methods. Asking an object for its meta-object (e.g. anObj.getClass() ) is called introspection. The introspection can go further and we can ask a meta-object what are its annotations (e.g. aClass.getAnnotations). Introspection and annotations belong to what is called reflection and meta-programming.

Also, it's not necessary to have main() method in your tests, but you can use main() method to run the TestNg tests if you want. Refer this.

According to official TestNG documentation, see "Command Line Parameters" table here http://testng.org/doc/documentation-main.html#running-testng , it should be possible with:

$ mvn test -Dexcludegroups=group3

However, for greater flexibility I would recommend to use test suite configuration file (aka testng.xml), the location of which can be configured via <suiteXmlFile> property of surefire-plugin, see: http://maven.apache.org/surefire/maven-surefire-plugin/examples/testng.html

This will allow to take a full control over groups inclusion/exclusion, see: http://testng.org/doc/documentation-main.html#exclusions

Put the method in a group and use dependsOnGroups.

class c1 {
  @Test(groups={"c1.verifyConfig"})
  public void verifyConfig() {
    //verify some test config parameters
  }
}

class c2 {
  @Test(dependsOnGroups={"c1.verifyConfig"})
  public void dotest() {
    //Actual test
  }
}

It is recommended to verify configuration in a @Before* and throw if something goes wrong there so the tests won't run. This way the tests can focus on just testing.

class c2 {
  @BeforeClass
  public static void verifyConfig() {
    //verify some test config parameters
    //Usually just throw exceptions
    //Assert statements will work
  }

  @Test
  public void dotest() {
    //Actual test
  }
}

This is "expected" behaviour. Not really nice, but it is how Arqullian works.

JUnit

• @BeforeClass / @AfterClass are only executed on ClientSide
• The state of the test class is lost between @Test, in container the whole lifecycle is repeated for each test
• @Before / @After are executed depending on the runmode (client/server)

TestNG

• everything is run both on server and client