How to use newTestMethodExecutor method of org.testng.thread.Interface IExecutorFactory class

Most testing frameworks (the xUnit family) are based on the JUnit framework. The Assert family of functions in JUnit have the (expected, actual) format; it became a convention, and most of the other frameworks followed that convention.

Some frameworks (like TestNG or NUnit 2.4+ for .NET) reversed that order (with the use of a constraint-based model for NUnit) to increase readability ("make sure that the actual value is 56" feels more natural than "make sure that 56 is the actual value").

The bottom line is: stick to the convention of your framework. If you use JUnit, put the expected value first. If you use TestNG, put the actual value first. You're right, that makes no difference in the test results when you accidentally reverse the arguments. But it makes a big difference in the default message you get from a failing test. When your reversed assertEquals(ShouldBeTrueButReturnsFalse(), true) in JUnit fails, the default message says "expected [false] but found [true]", where it should have said "expected [true] but found [false]". This is confusing, to say the least, and you shouldn't have to deal with a possible misdirection of that message.

Some of the unit tests in the Github link you provide don't follow the convention and have the same problem. Don't do that. Stick to the convention of your framework.

Unfortunately, the @Test annotation doesn't allow for catching multiple exception types (api reference http://junit.sourceforge.net/javadoc/org/junit/Test.html).

As a first option, I would advocate moving to TestNG. If your team won't allow that, there are few things you can do in JUnit.

Definitely use parameterized test cases so that you don't have to write one test function per test case (http://junit.sourceforge.net/javadoc/org/junit/runners/Parameterized.html). From here, there are a few options.

1. Group your test data by exception types.

   @Test (expected = IllegalArgumentException.class)
   public void testIllegalArgumentException(String username, String message, String topic) {}
   
   @Test (expected = NullPointerException.class)
   public void testNullPointerException(String username, String message, String topic) {}
   

2. Combine the exception types in your method signature. (This is what I recommend) Rough outline below ...

   public void testException(String username, String message, String topic, Class<? extends Exception>[] expectedExceptionClasses) {
       try {
           // exception throwing code
       } catch (Exception e) {
           boolean found = false;
           for (Class<?> expectedException : expectedExceptions) {
               if (e instanceof expectedException) {
                   found = true;
               }
           }
           if (found) {
               return;
           }
       }
       Assert.fail();
   }
   

3. Put all of your tests under the umbrella Exception class (I have a feeling you don't want to do that.).

   @Test (expected = Exception.class)
   public void testException(String username, String message, String topic) {}
   

There really isn't a "good" way to do this. The best thing I can suggest would be TestNG, which allows you to annotate your test methods and cause them to be executed in n threads concurrently. For example:

@Test(invocationCount=10, threadPool=10)
public void testSomethingConcurrently() {
    ...
}

My TestNG knowledge is rusty at best, but AFAIK that should invoke the testSomethingConcurrently method 10 times concurrently. This is a nice and declarative way to run multi-threaded tests against your code.

You can of course do something similar in JUnit by spawning threads manually in a loop, but that's insanely ugly and difficult to work with. I had to do this once for a project I was working on; those tests were a nightmare to deal with since their failures weren't always repeatable.

Concurrency testing is difficult and prone to frustration, due to its non-deterministic nature. This is part of why there is such a big push these days to use better concurrency abstractions, ones which are easier to "reason about" and convince one's self of correctness.

JUnit uses that syntax to show why a test failed, and specifically when an expected String didn't match the actual value:

String expected = "[1, 2, 3, 4, 5, 6, 7, 8, 9, 89]";
List<Long> actualLongs = Arrays.asList(
  1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L, 
  1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L, 89L);
String actualString = actualLongs.toString();
assertEquals(expected, actualString);

JUnit figures out the what's similar and different between the expected and actual, and uses the square brackets to highlight that. If you align the "expected" and "but was" bits, you get:

expected:<..., 4, 5, 6, 7, 8, 9, []89]>
 but was:<..., 4, 5, 6, 7, 8, 9, [1, 2, 3, 4, 5, 6, 7, 8, 9, ]89]>

... so it's telling you that in that [] space, it expected nothing extra, but found the characters 1, 2, 3, 4, 5, 6, 7, 8, 9,.

The difference becomes a bit more obvious if it's not just extra characters. For instance, let's say you didn't have the extra values, but the last 89 were instead a 66. Then it would look like:

expected:<..., 4, 5, 6, 7, 8, 9, [89]]>
 but was:<..., 4, 5, 6, 7, 8, 9, [66]]>

"Where I expected an 89, I found a 66."

I'm not as familiar with TestNG, but it wouldn't surprise me if it does a similar thing.

If you run the test in IDEA IntelliJ, it will even pick up on that syntax and show you a nice diff view of the expected-but-was. Again, I'm not familiar with other IDEs (like Eclipse), but it wouldn't surprise me if they do that as well.

If you want to avoid having to annotate each and every method with the data provider, you can use a Factory instead.

public class SearchTest1 {
    private final SearchType searchType;

    public SearchTest1( SearchType searchType ) {
       this.searchType = searchType;
    }

    @Test
    public void test2() {
        //Do the test2 logic
    }
    ...
}

And your factory class will be:

public class SearchTestFactory {
   @Factory
   public Object [] createInstances() {
      return new Object[] { new SeartchTest1( SearchType.ONE ), new SearchTest1( SearchType.TWO ) };
   }
}

See more on this here.

Then you can either have one factory that enumerates every test class or a separate factory for each, the first one is obviously less flexible, the second one means slightly more code.

taskkill is a standard Windows utility. The fact that Selenium cannot find it means that the environment variable PATH does not include the directory that contains standard system utilities. It is C:\Windows\system32 for modern Windows versions.

Add this directory to the PATH variable (follow this instruction to modify the PATH variable: http://www.computerhope.com/issues/ch000549.htm) and restart the console or IDE where you run Selenium scripts to apply this environment change.

I have create some general example for you - test with injection example

It works as you're expecting, I hope. It provides some test configs, injects them to driver and at last driver is injected in test component.

Result test looks like:

import com.google.inject.Inject;
import org.testng.annotations.Guice;
import org.testng.annotations.Test;

@Guice(modules = {TestModule.class})
public class SimpleTest {

    @Inject
    ComponentUnderTest component;

    @Test
    public void sampleTest() {
        System.out.println(component.getParamToTest());
        System.out.println(component.param);
        System.out.println(component.elseone);
    }

}

JUnit simply can't yet (at time of writting, 2022).

But both JExample and TestNG have something like that.

• Said libraries provide their own test runner, which supports their dependency mechanism.
• And both can be used alongside JUnit (without need to rewrite existing classes).
• But TestNG seems more promising.

I don't know how useful it is, but if you try it, please come back to tell us whether it was useful.

One of the easiest ways is ServletTester from Jetty. Everything is done within embedded Jetty automatically, so there is no port opened during the testing! If you use Maven than the following artifact is required to enable this method:

<dependency>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-servlet-tester</artifactId>
  <version>6.1.16</version>
  <scope>test</scope>
</dependency>

Example:

Prepare ServletTester

ServletTester tester=new ServletTester(); 
tester.addServlet(HelloServlet.class, "/hello"); 
tester.start();

Create HTTP request

HttpTester request = new HttpTester(); 
request.setMethod("GET");
request.setHeader("Host","tester"); 
request.setURI("/hello");
request.setVersion("HTTP/1.0");

Call servlet and retrieve response:

HttpTester response = new HttpTester();
response.parse(tester.getResponses(request.generate()));

Assert what you want to check on response and it's content:

assertEquals(200,response.getStatus()); 
assertEquals("Hello Servlet",response.getContent());