How to use Enum XMLReporterConfig.StackTraceLevels class of org.testng.reporters package

In IDEA, Maven project tab, click on the Show dependencies button (it will show a diagram) , then press Ctrl+ F in that diagram and type httpcore and check the version. if it shows the version less than 4.4 , you can analyze how dependencies has been resolved. Based on that you can adjust the pom to rectify the dependencies. Since it is working with mvn in the command line, this might be a incorrect behavior of the that IDEA resolve maven dependencies through its maven plugin.

Usually this information is provided in TestNG report.

If you need this time while running test suite, in @AfterMethod use ITestResult object:

@AfterMethod
public void getRunTime(ITestResult tr) {
    long time = tr.getEndMillis() - tr.getStartMillis();
}

Related: TestNG Dependency injection

In Intellij, go to "edit configurations" (Run -> Edit Configurations), in the configuration tab that comes up in the line "shorten command line" select option "classpath file"/"@argFiles (Java 9+)", last option in the drop down menu. Fixed it for me.

I don't know of any standard way to do this with JUnit. The reason for it, as you probably already know, is that your test cases should run independently of each other. This concerns the "normal" setup/teardown methods which run before and after each test method. Class setup and teardown is a bit different though - although I would still prefer running my tests independently and staying out of the trouble zone.

However, if you really are convinced of what you are doing, you could use a global flag to signal whether or not the class setup/teardown is to run, and to check for its state in the class setup/teardown methods. In your test suite, you could include a special class as the very first one, which does nothing more than execute the setup and set the global flag to indicate to the real test cases that their class setup/teardown methods must not be run. Similarly, a special last class in the suite can execute the teardown code. The caveat is that I am afraid JUnit does not guarantee the order of execution of test classes inside a suite, although most probably it does execute them in the specified order - but this is just an implementation detail. Try it out, it may work for you - but there is no guarantee it will always do what you expect.

You really want the test to do one thing, and to test for that. If you're not sure as to which exception is going to be thrown, that doesn't sound like a good test to me.

e.g. (in pseudo-code)

try {
   badOperation();
   /// looks like we succeeded. Not good! Fail the test
   fail();
}
catch (ExpectedException e) {
   // that's fine
}
catch (UnexpectedException e) {
   // that's NOT fine. Fail the test
}

so if you want to test that your method throws 2 different exceptions (for 2 sets of inputs), then you'll need 2 tests.

Here is some sample code, provided you use Java 7:

@DataProvider
public Iterator<Object[]> testData()
    throws IOException
{
    final List<Object[]> list = new ArrayList<>();

    for (final String line: Files.readAllLines(Paths.get("whatever"),
        StandardCharsets.UTF_8)
        list.add(new Object[]{ line, process(line) };

    return list.iterator();
}

private static Whatever process(final String line)
{
    // whatever
}

By convention, the test classes must also end with "Test". If they don't, you should add

<includes>
    <include>**/*.java</include>
</includes>

to your surefire config (or whatever includes work for you and your file naming scheme).

Change @AfterMethod to @AterClass or change @BeforeClass to @BeforeMethod

And on a side note, I would change --> static WebDriver driver; to private WebDriver driver;

Sauce Labs On Demand has a great plugin for Jenkins (https://saucelabs.com/jenkins/5). Their approach is pretty simple: you check/uncheck what OSs and browsers you to test and Jenkins sets environment variables for your tests to pick up. Below is a complete example of using Spring's @Configuration:

package com.acme.test;

import java.net.MalformedURLException;
import java.net.URL;

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.config.ConfigurableBeanFactory;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Scope;
import org.springframework.core.env.Environment;

@Configuration
public class SauceLabsWebDriverConfiguration {

    @Autowired private Environment environment;

    @Bean
    @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
    public WebDriver webDriver() throws MalformedURLException {
        DesiredCapabilities capabilities = new DesiredCapabilities();
        capabilities.setCapability("version", environment.getProperty("SELENIUM_VERSION", "17.0.1"));
        capabilities.setCapability("platform", environment.getProperty("SELENIUM_PLATFORM", "XP"));
        capabilities.setCapability("browserName", environment.getProperty("SELENIUM_BROWSER", "firefox"));
        String username = environment.getProperty("SAUCE_USER_NAME", "enter_your_username_here");
        String accessKey = environment.getProperty("SAUCE_API_KEY", "enter_your_api_here");
        return new RemoteWebDriver(new URL("http://" + username + ":" + accessKey + "@ondemand.saucelabs.com:80/wd/hub"), capabilities);
    }
}

Sauce Labs has some free plans, but if you don't want to use them, you should be able to switch out the last part that constructs the URL ("http://" + username + ":" + accessKey + "@ondemand.saucelabs.com:80/wd/hub") the actual server URL you want to point to ("http://mydomain.com").

The trick is basically to replace hard-coded browser/capability names with environment provided ones and then have your build runner (ant/maven/etc) set environment variables for each of the OS/browser combos you want to test and "loop" over those somehow. SauceLabs plugins just makes it easy to do the looping. You can still provide default fallback values in case you want to run a simple local test.

// Before
DesiredCapabilities firefoxCapabs = DesiredCapabilities.firefox();
capabillities.setCapability("version", "26");
capabillities.setCapability("platform", Platform.WINDOWS);

// After 
DesiredCapabilities capabilities = new DesiredCapabilities();
capabilities.setCapability("version", environment.getProperty("SELENIUM_VERSION", "17.0.1"));
capabilities.setCapability("platform", environment.getProperty("SELENIUM_PLATFORM", "XP"));
capabilities.setCapability("browserName", environment.getProperty("SELENIUM_BROWSER", "firefox"));

Hope it helps.