How to use Interface IAssertLifecycle class of org.testng.asserts package

It's a common pattern used to check the compliance of implementations of some spec. This is called a TCK, Technology Compatibility Kit. I've not looked at the code of many TCKs, but I've seen them often using TestNG.

There was a recent addition to JUnit 5.8.0-M1 that allows to define test suites that can be used for this, too.

Your TCK has a non-test dependency on your API and org.junit.jupiter:junit-jupiter (at least 5.8.0-M1) plus org.junit.platform:junit-platform-suite (at least 1.8.0-M1). The tests are not in src/test/java but src/main/java. Then you add a suite class to your TCK like:

package org.example;

import org.junit.platform.suite.api.SelectPackages;
import org.junit.platform.suite.api.Suite;

@Suite
@SelectPackages("org.example")
public abstract class TestCompatibilityKitSuite {}

Note that this class doesn't have to be abstract, I just think it makes the intended usage more clear.

The implementation then has a dependency on the api and a test dependency on the tck. To run the tests, add a class like:

package test;

import org.example.TestCompatibilityKitSuite;

class TckTest extends TestCompatibilityKitSuite {}

The TCK has to load the implementation. A good way to do so is by using a java.util.ServiceLoader. For a full example look here.

You might want to run

mvn -Dtest=SeosSdkAutomationApplicationTests test

in the directory that contains your pom.xml file to execute just this one test class.

But as @M.Deinum said, your setup looks flawed, trying to execute a TestNG test inside a Junit test.

Selenium Grid

Selenium Grid was built to allow multiple selenium sessions to be ran and handled automatically. It is configurable for multiple devices (when used in conjunction with appium), allows for parallel or standard testing and allows you to create nodes for each device based on a capability system.

Hub

Selenium Grid hub is a central server which manages the ability to run multiple tests.

1. Download the Selenium Standalone Server

2. Run the following to start the hub:

   $java -jar path/to/selenium-server-standalone-X.X.X.jar -role hub -port 4444 
   

Node

1. Install node.js

2. Install appium (unless you already have)

   $npm install –g appium
   

3. You will need a JSON file for each node, which outlines the capabilities of the device (or devices) that this node is to be used for:

{
"capabilities":
[
{
"browserName": "Chrome",
"deviceName": "deviceName",
"device": "device",
"udid":"XXXXXXXX",
"version":"X.X.X",
"maxInstances": 5,
"platform":"ANDROID",
"platformName": "Android"
}
],
"configuration":
{
"cleanUpCycle":2000,
"timeout":10000,
"proxy": "org.openqa.grid.selenium.proxy.DefaultRemoteProxy", 
"url":"http://0.0.0.0:4723/wd/hub",
"maxSession": 5,
"port": 4723,
"host": "0.0.0.0",
"register": true,
"registerCycle": 5000,
"hubPort": 4444,
"hubHost": "localhost"
}
}

Keep in mind each node needs to use a different port for the url and port configurations. 4723, for example.

4. Create a node

   $appium --nodeconfig /Path/To/Config.json -p 4723 -bp 5723 --chromedriver-port 6723
   

Each node needs three unique ports (Port, Bootstrap Port, ChromeDriver Port) and the port specified with -p I found needs to be the same as the port given in the config.

Testing

I would recommend using a testing framework such as TestNG or JUnit, which will allow you to run test suites and pass capabilities in @BeforeClass methods etc.

But essentially all you need to do is create a AndroidDriver using capabilities identical to those specified in your JSON config file for a certain node and then that instance of AndroidDriver will be associated with that specific node (Selenium Grid handles this) and furthermore with the device which the node is associated with. It's very simple really, once you know what you are doing!

Initialise AndroidDriver like this:

driver.set(new AndroidDriver(new URL(SELENIUM_HUB_URL),
                capabilities)); 

A common mistake people make is passing the AndroidDriver the node URL instead of the Hub URL (http://0.0.0.0:4723/wd/hub instead of http://0.0.0.0:4444/wd/hub) this is really common because it will, at least initially work, but then when trying to use any Selenium Grid specific functionality (such as multiple devices) everything will break.

Good luck and I hope this helps,

Liam

If you are using default authentication from JIRA, then preemptive authentication is what you need. Below are the sample code.

RestAssured.baseURI = System.getProperty("baseurl");
PreemptiveBasicAuthScheme authScheme = new PreemptiveBasicAuthScheme();
authScheme.setUserName("admin");
authScheme.setPassword("admin");
RestAssured.authentication = authScheme;

The sample code will help you do the authentication before every request you send.

In unix environment the delimiter for classpath is : so change it to:

export CLASSPATH=/home/admin/TagAPI/lib/org.json-20120521.jar:/home/admin/TagAPI/lib/testng-6.8.21.jar 

; is the command delimiter.

The answer is to create a shutdown hook via Runtime's addShutdownHook method, like this:

static volatile boolean cleanedUp = false;
static final Object lock = new Object();

@BeforeClass
public static void setup() {
    Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
        public void run() {
            MyTestClass.tearDown();
        }
    }
}

@AfterClass
public static void tearDown() {
    synchronized (lock) {
        if (cleanedUp) return;
        // do clean up
        cleanedUp = true; 
    }         
}

Using the synchronization ensures the clean up is only executed once.

You don't need annotations to achieve this, since it's exactly what the finally block is intended for:

@Test
public void passengerServiceTest() {            
    try {
        //test code 
    } finally {
        deleteCreatedPassenger();
    }
}

public void deleteCreatedPassenger() {
...    
}

If the delete throws an exception then your service test fails.

Annotations are useful in certain scenarios, you shouldn't aim to use them over core language constructs.

Naif,

Actually, your above question is different than the actual question hence you should have asked it as a separate question. Still, I'm answering to your previous question.

The error is because the element you're trying to click on isn't visible. Before you click on element, it should be visible. You can do this by following -

WebElement element = driver.findElement(By.xpath("//div[2]/div[2]"));
WebDriverWait wait = new WebDriverWait(driver, 20); //here, wait time is 20 seconds

wait.until(ExpectedConditions.visibilityOf(element)); //this will wait for elememt to be visible for 20 seconds
element.click(); //now it clicks on element

If above doesn't work, you can click on element by executing javascript(but this isn't a good practice)

JavascriptExecutor js = (JavascriptExecutor)driver;
js.executeScript("arguments[0].click();", element);

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.