How to use startElement method of org.testng.xml.TestNGContentHandler class

Jersey comes with a great RESTful client API that makes writing unit tests really easy. See the unit tests in the examples that ship with Jersey. We use this approach to test the REST support in Apache Camel, if you are interested the test cases are here

Inner static class configuration: When testing Spring components we usually use @RunWith(SpringJUnit4ClassRunner.class) and make our class @ContextConfiguration. By making class @ContextConfiguration you can create an inner static class for configuration and in it you have full control. There you define all you need as beans and @Autowired it in your test, along with dependencies which can be mocks or regular objects, depending on test case.

Component scanning production code: If there are more components needed for test you can add @ComponentScan but we try to make it scan only packages it needs (this is when you use @Component annotation but in your case you can add XML to @ContextConfiguration). This is a good choice when you do not need mocks and you have a complicated setup which needs to be production like. This is good for integration tests where you want to test how components interact with each other in functional slices you want to test.

Hybrid approach: This is the usual case when you have many beans which need to be production like but one or two need to be mocks. Then you can @ComponentScan production code but add an inner static class which is @Configuration and there define beans with annotation @Primary which will override production code configuration for that bean in case of tests. This is good since you do not need to write long @Configuration with all defined beans, you scan what you need and override what should be mocked.

In your case I would go with first approach like this:

package org.world.hello;

import static org.junit.Assert.*;
import org.mockito.Mockito;
import org.junit.Test;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class RoomTest {

    @Configuration
    //@ImportResource(value = {"path/to/resource.xml"}) if you need to load additional xml configuration
    static class TestConfig {
       @Bean
       public BottleCounter bottleCounter() {
        return Mockito.mock(BottleCounter.class);
       }

       @Bean
       public Room room(BottleCounter bottleCounter) {
         Room room = new Room();
         room.setBottleCounter(bottleCounter);
         //r.setNumBottles(3); if you need 3 in each test
         return room;           
       }
    }

    @Autowired
    private Room room;  //room defined in configuration with mocked bottlecounter

    @Test
    public void testThreeBottlesAreSeperatedByNewLines()
    {
        Mockito.when(b.countBottle(Mockito.anyInt())).thenReturn("a");
        r.setNumBottles(3);
        assertEquals("a\na\na\na\n", r.generatePoem());
    }

}

Effective January 15, 2020, The Central Repository no longer supports insecure communication over plain HTTP and requires that all requests to the repository are encrypted over HTTPS.

If you're receiving this error, then you need to replace all URL references to Maven Central with their canonical HTTPS counterparts:

Replace http://repo1.maven.org/maven2/ with https://repo1.maven.org/maven2/

Replace http://repo.maven.apache.org/maven2/ with https://repo.maven.apache.org/maven2/

If for any reason your environment cannot support HTTPS, you have the option of using our dedicated insecure endpoint at http://insecure.repo1.maven.org/maven2/

For further context around the move to HTTPS, please see https://blog.sonatype.com/central-repository-moving-to-https.

Try setting an implicit wait of maybe 10 seconds.

gmail.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);

Or set an explicit wait. An explicit waits is code you define to wait for a certain condition to occur before proceeding further in the code. In your case, it is the visibility of the password input field. (Thanks to ainlolcat's comment)

WebDriver gmail= new ChromeDriver();
gmail.get("https://www.gmail.co.in"); 
gmail.findElement(By.id("Email")).sendKeys("abcd");
gmail.findElement(By.id("next")).click();
WebDriverWait wait = new WebDriverWait(gmail, 10);
WebElement element = wait.until(
ExpectedConditions.visibilityOfElementLocated(By.id("Passwd")));
gmail.findElement(By.id("Passwd")).sendKeys("xyz");

Explanation: The reason selenium can't find the element is because the id of the password input field is initially Passwd-hidden. After you click on the "Next" button, Google first verifies the email address entered and then shows the password input field (by changing the id from Passwd-hidden to Passwd). So, when the password field is still hidden (i.e. Google is still verifying the email id), your webdriver starts searching for the password input field with id Passwd which is still hidden. And hence, an exception is thrown.

Why to migrate? You can use JUnit for unit-testing and another framework for higher-level testing. In your case it is a kind of acceptance or functional or end-to-end, it is not that important how you name it. But important is to understand that these tests are not unit. They stick to different rules: they are more complex, run longer and less often, they require complex setup, external dependencies and may sporadically fail. Why not use another framework for them (or even another programming language)?

Possible variants are:

• BDD frameworks: already mentioned Cucumber, JDave, JBehave, Spock. For instance, Spock is JUnit based and Groovy =)
• TestNG

If adding another framework is not an option: you enumerated more options for JUnit then I could imagine =) I would put the whole test script for the flow in one test method and would organize test code into "Drivers". That means that your end-to-end tests do not call the methods of your application or Selenium API directly, but wrap them into methods of Driver components which hide API complexity and look like statements of what happens or what is expected. Look at the example:

@Test 
public void sniperWinsAnAuctionByBiddingHigher() throws Exception {
    auction.startSellingItem();

    application.startBiddingIn(auction);
    auction.hasReceivedJoinRequestFrom(ApplicationRunner.SNIPER_XMPP_ID);

    auction.reportPrice(1000, 98, "other bidder");
    application.hasShownSniperIsBidding(auction, 1000, 1098);

    auction.hasReceivedBid(1098, ApplicationRunner.SNIPER_XMPP_ID);

    auction.reportPrice(1098, 97, ApplicationRunner.SNIPER_XMPP_ID);
    application.hasShownSniperIsWinning(auction, 1098);

    auction.announceClosed();
    application.hasShownSniperHasWonAuction(auction, 1098);
} 

A snippet is taken from the "Growing Object-Oriented Software Guided by Tests". The book is really great and I highly recommend to read it.

This is real end-to-end test that uses real XMPP connection, Openfire jabber server and WindowLicker Swing GUI-testing framework. But all this stuff if offloaded to Driver components. And in your test you just see how different actors communicate. And it is ordered: after application started bidding we check that auction server received join request, then we instruct auction server to report new price and check that it is reflected in UI and so on. The whole code is available on github.

The example on github is complex, because the application is not as trivial as it usually happens with book examples. But that book gives it gradually and I was able to built the whole application from scratch following the book guide. In fact, it is the sole book I ever read on TDD and automated developer testing that gives such a thorough and complete example. And I've read quite a lot of them. But note, that Driver approach does not make your tests unit. It just allows you hide complexity. And it can (and should) be used with other frameworks too. They just give you additional possibilities to split your tests into sequential steps if you need; to write a user readable test cases; to externalize test data into CSV,Excel tables, XML files or database, to timeout your tests; to integrate with external systems, servlet and DI containers; to define and run separately test groups; to give more user-friendly reports and so on.

And about making all your tests unit. It is not possible for anything excluding something like utility libraries for math, string processing and so on. If you have application that is completely unit tested that it means either that you test not all application or you do not understand what tests are unit and what are not. The first case may be OK, but everything that is not covered must be tested and retested manually by developers, testers, users or whoever. It is quite common but it better to be conscious decision rather than casual one. Why you cannot unit test everything?

There are a lot of definitions of unit tests and it leads to holy war) I prefer the following: "Unit test is test for program unit in isolation". Some people say: "hey, unit is my application! I test login and it is simple unit function". But there is also pragmatics that hides in isolation. Why do we need to differ unit tests from others? Because it is our first safety net. They must be fast. You commit often (to git, for example) and you run them at least before each commit. But imagine, that "unit" tests takes 5 minutes to run. You will either run them less often or you will commit less often or you will run just one test case or even one test method at the time, or you will wait say each 2 minutes for tests to complete in 5 minutes. An in that 5 minutes you'll go to Coding Horror where you'll spend the next 2 hours =) And unit tests must never fail sporadically. If they do that - you will not trust them. Hence, the isolation: you must isolate slowness and sources of sporadic failures from your unit tests. Hence, isolation means that unit tests should not use:

• File system
• Network, Sockets, RMI and so on
• GUI
• Multithreading
• External libraries expecting test framework and supporting simple libraries like Hamcrest

And unit tests must be local. You want to have just one or so tests failing when you've made a defect within 2 minutes of coding, not a half of the whole suite. That means that you are very limited in testing stateful behavior in unit tests. You should not make a test setup that makes 5 state transitions to reach preconditions. Because fail in first transition will break at least 4 tests for following transitions and one more test that you currently write for the 6th transition. And any non-trivial application has quite a lot of flows and state transitions in it. So this cannot be unit tested. For the same reason unit tests must not use changeable shared state in database, static fields, Spring context or whatever. This is exactly the reason why JUnit creates new instance of test class for every test method.

So, you see, you cannot fully unit test a web app, no matter how you recode it. Because it has flows, JSPs, servlet container and probably more. Of course, you can just ignore this definition, but it is damn useful) If you agree that distinguishing unit tests from other tests is useful, and this definition helps to achieve that then you'll go for another framework or at least another approach for tests that are not unit, you'll create separate suites for separate kinds of test and so on.

Hope, this will help)

If you have same type of parameters then you can pass as a array in method parameter.

@Test (dataProvider = "Dataprovider1")
public void testScenario1(String args [])
            ) throws Exception {
    System.out.println(args[0]+"---------------- "+args[1]+" ---------------   "+args[3]+" .. so on");
}

Also if you have different type of parameter field then you can beak it with help of a helper class and then pass the reference of this class in parameter. e.g:

class Helper {
  String data1;
  String data2;
  String data3;
  Long data4;
  int data5;
  flot data6;
 -----so on------
 ----getter setter and constructor----
}

your test class

class Test {
@DataProvider(name="Dataprovider1")
public static Object[][] testData() {
    return new Object[][] {
            { new Helper("hey", "you", "guys" ..... another constructor parameters..) } }
    };

}

@Test (dataProvider = "Dataprovider1")
public void testScenario1(Helper helper) throws Exception {
    System.out.println(helper.data1+"---------------- "+helper.data2+" ---------------   "+helper.data3+" .. so on");
}
}

Follow the steps below:

Step# 1:

Create a custom annotation in a separate file (ie: SetTestName.java)

@Retention(RetentionPolicy.RUNTIME)
public @interface SetTestName {
    int idx() default 0;
}

Step# 2:

Create a base class implementing ITest interface of TestNG (TestNameSetter.java).

public class TestNameSetter implements ITest{
    private String newTestName = "";

    private void setTestName(String newTestName){
        this.newTestName = newTestName;
    }

    public String getTestName() {

        return newTestName;
    }


    @BeforeMethod(alwaysRun=true)
    public void getTheNameFromParemeters(Method method, Object [] parameters){
        SetTestName setTestName = method.getAnnotation(SetTestName.class);
        String testCaseName = (String) parameters[setTestName.idx()];
        setTestName(testCaseName);
    }
}

Step# 3:

Use your DataProvider like in the code snippet:

@DataProvider(name="userData")
 public Object[][] sampleDataProvider()
 {
  Object[][] data = {
    {"loginTestUS_Username","loginTestUSPass"}, 
    {"loginTestIN_Username","loginTestINPass"},
    {"loginTestJP_UserName","loginTestJPPass"}
  };

  return data;
 }



 @SetTestName(idx=0)
 @Test(dataProvider="userData")
 public void test1(String userName, String pass)
 {
     System.out.println("Testcase 1");
 }

 @SetTestName(idx=1)
 @Test(dataProvider="userData")
 public void test2(String userName, String pass)
 {
     System.out.println("Testcase 2");
 } 

That's all. Now, you will see your test name changed accordingly in the console.

Follow the link below for your query. I hope, you might get your desired answer here:

http://biggerwrench.blogspot.com/2014/02/testng-dynamically-naming-tests-from.html

Don't use annotations for your tests. Have a constructor that will wire in all your dependencies.

@Stateless
public class PersonServiceImpl implements PersonService {

    @EJB
    private RemotePersonService remotePersonService;

    // Let your test instantiate a mock service and wire it into your test instance using this constructor.
    public PersonServiceImpl(RemotePersonService rps) {
        this.remotePersonService = rps;
    }

    @Override
    public long countPersons() {
         return remotePersonService.getAllPersons().size();
    }
}

Create mocks and pass them to it. Your test might look like this:

@LocalClient
public class PersonServiceTest extends AbstractTest {

    @Test
    public void testPersonService() {
        RemotePersonService mockRemotePersonService = Mockito.mock(RemotePersonService.class);
        List<Person> customResults = new ArrayList<Person>();
        customResults.add(new Person("Alice"));
        customResults.add(new Person("Bob"));
              Mockito.when(mockRemotePersonService.getAllPersons()).thenReturn(customResults);
        PersonService personService = new PersonServiceImpl(mockRemotePersonService);
        long count = personService.countPersons();    
        Assert.assertEquals(count, 2l);
    }
}

I really don't get why IDEA must break up one test run's console outs to so many places in the tree, seems kind of silly.

The intent is so you can see output relevant to a specific test. This way, when running dozens, or hundreds, of tests, you can focus on the relevant output and not a lot of "noise" that is irrelevant to the the particular test you are focusing on.

However I don't see a post anywhere explaining how to actually log all of this to one log file.

This is typically done via your logging framework, not the IDE. (But there is a way to do this in IDEA w/o a logging framework, which I discuss below.) As an aside, Logback is ideal for this since it automatically looks for a test specific configuration file. Of course, with other frameworks, you can set a test specific configuration file.

If you create a run/debug configuration for running your test, you can add the log file's output to a tab in the run output tool window. In your run/debug configuration, click on the Logs tab and add the log that your logging framework writes to. You can also set it up so that only new/fresh output is shown in the tab preventing you from seeing logging from previous runs.

You can also select the "Save Console Output to File" option.

Finally, you can combine the above two settings, so that console output is logged to a file, and the output is shown in a second tab.

If you want either of the settings to to be the default, you can set it in the default "unit test" configuration. Expand the "Default" section in the Run/Debug configuration window (Run > Edit Configurations). When set there, any new run/debug unit test configurations (even temporary ones created on the fly via Ctrl+Shift+F10) will have those settings. Note that defaults only apply to the current project. If you want to make the setting a global default for all future projects, From the Welcome Screen (i.e. close all projects) go to "Configure" > "Project Defaults" > "Run Configurations" and make the setting there.