How to use ParallelBugTest class of org.mockito package

Check the Java API for List.
The get(int index) method is declared to throw only the IndexOutOfBoundException which extends RuntimeException.
You are trying to tell Mockito to throw an exception SomeException() that is not valid to be thrown by that particular method call.

To clarify further.
The List interface does not provide for a checked Exception to be thrown from the get(int index) method and that is why Mockito is failing.
When you create the mocked List, Mockito will use the definition of List.class to creates its mock.

The behavior you are specifying with the when(list.get(0)).thenThrow(new SomeException()) doesn't match the method signature in List API, because get(int index) method does not throw SomeException() so Mockito fails.

If you really want to do this, then have Mockito throw a new RuntimeException() or even better throw a new ArrayIndexOutOfBoundsException() since the API specifies that that is the only valid Exception to be thrown.

The easiest (only?) approach, IMHO, would be to use the thenAnswer method, which allows you to not only return a value, but actually execute some code. Java 8 makes this particularly elegant, as you could just use an anonymous lambda:

when(myMock.myFunction(anyString()))
    .thenAnswer(i -> new MyObject((String)i.getArguments()[0]);

Several of the methods on AbstractHttpClient are final and thus won't be mocked. IMO, this behavior is the #1 reason not to mock concrete classes.

After a lot more hunting around and looking at all the options Mockito/Powermock had to offer, I found the solution (which I will share in case others run into this same issue).

When you have private member variables that are never initialized (and just assumed created in other places), you can use the @InjectMocks annotation to "inject" Mocks you want into your class you are testing.

1. Add a variable in your test class for the class you are testing, and give it the annotation @InjectMocks (org.Mockito.InjectMocks).
2. Use @Mock annotations to setup the mocks you want to inject. Use the @Mock (name = "privateVariableNameHere") name property to map the Mock object to the private variable inside your class you are testing.
3. In either a setup function or before you call your class, initialize the mocks. The easiest way I have found is to use a "setup" method with the @Before annotation. Then inside there call MockitoAnnotations.initMocks(this); to quickly initialize anything with the @Mock annotation.
4. Define your Mock functionality in your test method (before calling the method you are testing).
5. Using the @InjectMock object, call your method you are testing... the mocks SHOULD be hooked in and working as defined in the earlier steps.

So for the example class I use above, the code to test/mock would have Connection returned as a mock which you can do whatever with. Based on the example above in my question, this is what the code would look like:

@RunWith(PowerMockRunner.class)
@PrepareForTest({/* Static Classes I am Mocking */})
public class ExampleTest {
  @Mock (name = "queueFactory") //same name as private var.
  QueueConnectionFactory queueFactoryMock;
  @Mock
  Connection connectionMock; //the object we want returned
  @InjectMocks
  Example exampleTester; //the class to test

  @Before
  public void setup(){
    MockitoAnnotations.initMocks(this); // initialize all the @Mock objects
    // Setup other Static Mocks
  }

  @Test
  public void testTestMe(){
    //Mock your objects like other "normally" mocked objects
    PowerMockito.when(queueFactoryMock.createConnection()).thenReturn(connectionMock);
    //...Mock ConnectionMock functionality...
    exampleTester.testMe();
  }
}

There are two testing strategies. One is unit testing, i.e. making sure your service works. The other is integration/end-to-end testing, i.e. making sure everything plays nicely together.

You unit test stuff you own, you integration test everything you have. This is a pretty rough example using just your statement, plus some made up stuff where I can't fill in the blanks.

Unit Tests

Using Mockito

PersonRepository personRepository = mock(PersonRepository.class);

@TestSubject
PersonService personService = new PersonService(): 

@Test
public void unitTest() {
    personService.setPersonRepository(personRepository);
    Person person = new Person(1L);
    Person person2 = new Person(1L);

    when(personRepository.returnPerson(1L)).thenReturn(person2); //expect a fetch, return a "fetched" person;

    personService.deleteFromPerson(person);

    verify(personRepository, times(1)).delete(person2); //pretty sure it is verify after call
}

Using EasyMock...

@Mock
PersonRepository personRepository; //assuming it is autowired

@TestSubject
PersonService personService = new PersonService(): 

@Test
public void unitTest() {
    Person person = new Person(1L);
    Person person2 = new Person(1L);

    EasyMock.expect(personRepository.returnPerson(1L)).andReturn(person2); //expect a fetch, return a "fetched" person;
    personRepository.delete(person2);
    EasyMock.expectLastCall(); //expect a delete for person2 we plan to delete
    replayAll();

    personService.deleteFromPerson(person);

    verifyAll(); //make sure everything was called
}

Yes, this test looks like it is written rigidly, but that's really all you're testing in the unit test, anyways. You want the DB to fetch a Person from the database using an argument, hence why there are two Person objects, and you expect to delete that passed Person object, which is why you expect the call. Simple method yields simple test. You basically want to ensure you're interacting with your repository as you expect. Repository could be broken or null in actual implementation, but that doesn't change the fact that your service is implemented correctly.

Integration Tests

On the other hand, if you want to do an integration test, no mocking is used. Instead, you'll need to wire up everything like a test DB and repo. I'll leave that up to you since there's no reference for implementation.

@Test
public void integrationTestForAddAndDelete() {
    Person person = createDummyPersonForInsertion(); //static method that creates a test Person for you
    Person comparePerson;
    //make sure we haven't added the person yet
    Assert.assertNull(personService.getPerson(person));

    //add the Person
    comparePerson = personService.addPerson(person);
    Assert.assertNotNull(personService.getPerson(person));
    //add a rigorous compare method to make sure contents are the same, i.e. nothing is lost or transmuted incorrectly, ignoring ID if that is autogen
    //alternatively, you can create a unit test just for Person
    Assert.assertEquals(person, comparePerson); 

    //remove the Person
    personService.deleteFromPerson(person);
    Assert.assertNull(personService.getPerson(person));

    //test for exception handling when you try to remove a non-existent person;
    personService.deleteFromPerson(person);

    //test for exception handling when you try to remove null
    personService.deleteFromPerson(null);
}

In this case, you want to make sure your repo actually handles all the calls from the service. You know your service works from the unit test, but does the repo work from the service or have you configured something wrong

Dependency Injection

If you inject the Bar instance, or a factory that is used for creating the Bar instance (or one of the other 483 ways of doing this), you'd have the access necessary to do perform the test.

Factory Example:

Given a Foo class written like this:

public class Foo {
  private BarFactory barFactory;

  public Foo(BarFactory factory) {
    this.barFactory = factory;
  }

  public void foo() {
    Bar bar = this.barFactory.createBar();
    bar.someMethod();
  }
}

in your test method you can inject a BarFactory like this:

@Test
public void testDoFoo() {
  Bar bar = mock(Bar.class);
  BarFactory myFactory = new BarFactory() {
    public Bar createBar() { return bar;}
  };
  
  Foo foo = new Foo(myFactory);
  foo.foo();

  verify(bar, times(1)).someMethod();
}

Bonus: This is an example of how TDD(Test Driven Development) can drive the design of your code.

PowerMockRunner is part of powermock-module-junit4.jar. You need to explicity import this jar

You could specify the dependency for this jar as per your requirement. Refer to this link.

It sounds like you may want to be using the .expects(1) type methods that mock frameworks usually provide.

Using mockito, if you were testing a List and wanted to verify that clear was called 3 times and add was called at least once with these parameters you do the following:

List mock = mock(List.class);        
someCodeThatInteractsWithMock();                 

verify(mock, times(3)).clear();
verify(mock, atLeastOnce()).add(anyObject());      

Source - MockitoVsEasyMock

For those who are using the newer version of swagger, here is the solution for accessing the swagger ui page.

Replace this:

    <dependency>
        <groupId>io.springfox</groupId>
        <artifactId>springfox-swagger2</artifactId>
        <version>2.8.0</version>
  </dependency>
    <!-- https://mvnrepository.com/artifact/io.springfox/springfox-swagger-ui -->
    <dependency>
        <groupId>io.springfox</groupId>
        <artifactId>springfox-swagger-ui</artifactId>
        <version>2.8.0</version>
    </dependency>

with this:

<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-boot-starter</artifactId>
    <version>3.0.0</version>
</dependency>

in your pom.xml file.

Access the page via the following url (avoid that .html extension): http://localhost:8080/swagger-ui/

Rebuild and restart the server. And your problem is solved!